view release on metacpan or  search on metacpan

docs/patterns.otl  view on Meta::CPAN

Patterns of Object Interaction
	Abstract
		A useful object framework must support all possible design and interaction patterns.
			The framework must support a core suite of general-purpose design patterns.
			The framework must provide a good foundation for external implementation of additional patterns.
		Top-down design is impossible.
			An object framework must support all future uses, but it cannot anticipate them.
			People write programs, and people are unpredictable.
		Bottom-up design tends to fail.
			Simple conceptual models work well at small scales.
				Growing complex systems from basic principles is difficult.
				There is an early, seductive sense of success.
			Simple conceptual models often fail over time.
				Larger systems strain the requirements of simple conceptual models.
				Prevailing best practices change over time, and new practices introduce new requirements.
				The rules and corollaries eventually conflict.
				It's impossible to anticipate everything.
		A hybrid approach may succeed where the other two fail.
			It's easier to catalog meta design and interaction patterns than use cases.
			By cataloging basic object design and interaction patterns, certain basic requirements will emerge.
			By satisfying these requirements, the emergent object framework will conceptually scale farther.
	Roadmap
		Catalog and consider as many design and interaction patterns as possible.
		Describe the emergent meta patterns.
		Develop and document a syntax and specification to support the meta patterns.
		Implement the specification.
	Call for Contribution
		Please help.
		This is a huge project.
		The project leader has worked on bottom-up designs since 1998 and would like to get it right this time.
Object Structural Patterns
	Code Conventions
		Functions
		Methods
			Class Methods
			Object Methods
	Parameter Conventions
		Self and Positional Parameter List
		Self and Parameter Hashref
		Lexical Aliases
			Self
			Hashref Members
	Return Conventions
		Returned Data Formats
			Returned as a List
			Returned as a Hashref
			Type and Hashref
		Returned Data Mechanisms
			Return via Return Builtin
			Emitting via Method
				Synchronous Emit
					The emitted message target is called during emit().
					Bypassing queue latency is efficient.
					Deep recursion can occur.
					Broad recursion cannot occur.
					Requires deep Perl magic to work across process boundaries.
				Asynchronous Emit
					A message representing the emit() call is enqueued for the message target.
					Queue latency makes this slower than synchronous emit.
					Deep recursion cannot occur.
					Broad recursion can occur.
					May work locally or remotely.
				Hybrid Emit
					Synchronous emit is used whenever possible.
					Asynchronous emit is used at the first sign of recursion.
					Asynchronous emit may also be used for remote messages.
					Deep recursion cannot occur.
					Broad recursion is less likely.
	Constructor Conventions
		Direct Instantiation
			Instantiate in Another Thread
			Instantiate in Another Process
				Process Already Exists
				Process Doesn't Exist
		Instantiation upon Request
	Destructor Conventions

docs/patterns.otl  view on Meta::CPAN

			An object that receives a request and performs some kind of work.
			Called responders because they often respond to requests.
			Some objects perform side effects without responding.
			A universal sink (the /dev/null of objects) may neither respond nor perform a side effect.
			Consider calling them workers.
			Responders may consume requests.
			Responders may produce responses.
	To Do
		The producer/consumer and requester/responder combinations may need to be enumerated and explained in more detail.
	Discrete Transactions
		Ordinalities
			Point to Point
				One Requester, One Responder
			Broadcast and Gather
				One Requester, Any Responders
				Serial Responders
				Parallel Responders
			Message Channels
				Any Requesters, Any Responders
			Service
				Any Requesters, One Responder
	Multi-Transaction Sessions
		Ordinalities
			Point to Point
				One Connector, One Service
	Observation and Notification
		Terms
			Notifier
				An object that advertises notifications when its data members change.
			Observer
				An object that observes data member changes in one or more other objects.
				An object may observe its own data members.
		Ordinalities
			No Notifiers, Any Observers
				Ideally the system will optimize this case into a no-op.
				Runtime support for dynamic ordinalities may prevent optimization.
			Any Notifiers, No Observers
				Ideally the system will optimize this case into a no-op.
				Runtime support for dynamic ordinalities may prevent optimization.
			One Notifier, One or More Observers
				Notofication is sent to all observers.
			One or More Notifiers, One Observer
				An observer may observe more than one notifier.
				It remains to be seen whether this case is practical.
			Multiple Notifiers, Multiple Observers
				The observation/notification equivalent of a data bus.
				It also remains to be seen wheter this is practical.
		Notifications
			Notification on Set
				Observers are notified whenever a value is written to an observed member.
				Obseration occurs even when the new value is identical to the old one.
				Level-triggered notification.
			Notification on Change
				Observers are notified whenever a new value is written to an observed member.
				Obseration does not occur when the new value is identical to the old one.
				Edge-triggered notification.
Continuation Patterns
	About
		Continuations are encapsulated bits of program state that can be passed around and swapped in and out as needed.
		Each continuation includes an instruction pointer and all the program state required to resume a program from that point in its execution.
		Perl supports coroutines by grafting its interpreter onto an event dispatcher.
		This grafting is done deep in its implementation using sharp implements.
		Continuations may also be implemented as explicit objects to manage execution state between callbacks.
		Event frameworks like POE implement such continuations, albeit at a rather low level.
		Multiple continuations may be active at once.
		Continuations may be nested, in which case the inner continuation should run to completion before the outer one may resume.
		Lexical::Persistence
			Lexical::Persistence was written to map continuation object data members into lexical pads.
			This simplifes their use---lexical variables magically refer to the right continuation.
			It's somewhat off-putting magic, however.
			Perl seems to behave abnormally.
			An alternative, explicit mechanism might feel nicer.
	Request Based Continuations
		About
			Tasks require their own continuations.
			Each task is initiated by some form of request.
			The request may be implicit in an object's creation.
			It may be an explicit message sent to a service.
		Inbound Request Continuations
			Inbound request continuations are state associated with tasks that one object or service performs on behalf of another.
			These continuations are associated with inbound requests.
			They are accessible within receivers of requests.
			They are automatically made available whenever code is executed as a consequence of the initial request.
			In other words, these continuations are in scope during the performance of a task triggered by some request.
		Outbound Request Continuations
			Outbout request continuations associated with tasks that are being performed by another object upon the current object's request.
			These continuations are associated with outbound requests.
			They are accessible within request senders, or method callers.
			They are automatically made available whenever a response is received by the helper object or service.
			These continuations provide continuity between asynchronous messages and the responses they generate.
	Object Based Continuations
		Self Continuations
			Each object has a continuation that is in scope whenever the object is active.
			This continuation is the object itself.
		Parent Object Continuations
			These continuations are special cases of Inbound Request Continuations.
			They exist when the parent object created the current object for the purpose of performing a task.
			Are there other useful uses of parent object continuations?
		Child Object Continuations
			These continuations are special cases of Outbound Request Continuations.
			They exist when the parent object created the current object for the purpose of performing a task.
			Are there other useful uses of parent object continuations?
	Connection Based Continuations
		About
			Persistent connections or sessions between objects are useful.
			Continuation scope and lifetime can be associated to persistent connections.
			Management of connection state is automated as a result.
		Connector's Continuation
			Connector continuations are associated with the client sides of connections between objects.
			They provide continuity over the course of the connection.
			Additionally, outbound request continuations may be associated with individual requests that are sent down connections.
		Service's Continuation
			Service continuations are associated with the server sides of connections between objects.
			They provide continuity within the service over the course of the connection.
			Additionally, inbound request continuations may be associated with individual requests that a service may receive.
	Lexical Aliases for Continuation Variables
		About
			Lexical::Persistence was written to provide easy lexical aliases for continuation variables.
			Members of a continuation object may be aliased to lexical variables within a callback.
			Accessing or modifying lexical variables magically does the same to members of the continuation object.
			However, the aliasing incurs overhead and is not lazy.