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
		Destruction upon Release
			Owner Explicitly Releases Object
			Cascaded Owner Destruction
			Global Destruction
		Destruction upon Request
			External Shutdown Request
			Avoid Shutdown upon Destruction
				Shutdown upon destruction tends to be too late.
				Shutdown may take time.
				Objects in the throes of destruction don't have time.
		Self-Destruction upon Task Completion
			Relies upon weak references or implicit management.
			May be thwarted by users holding onto additional object references.
				Accidentally, causing memory leaks.
				Explicitly, but power users.
		Object Never Destructs
			Do nothing vital within object destructors.
			Object destructor invocation is not guaranteed.
			POSIX::_exit()
			Signals.
Object Composition Patterns
	Static Class Composition
		Inheritance
		Interfaces and Implementations
		Roles
	Object Composition
		Static Object Composition
			Low-level objects that comprise a higher-level object are created along with the high-level object.
			The instantiation-time configuration persists until destruction.
		Dynamic Object Composition
			A higher-level object creates and by default owns lower-level objects as needed.
			The type and ordinality of lower-level objects may change over time.
		Object Composition Roles
			Lower-level objects fulfill roles within their higher-level objects.
			Higher-level objects may assign role names to lower-level objects to simplify addressing and management.
			Role Ordinalities
				No Objects per Role
					All objects for a role may have destructed, or no objects for a role may have been constructed yet.
				One Object per Role
					Each lower-level object comprising a higher-level object may have its own role, or no role at all.
				Multiple Objects per Role
					Multiple objects may be assigned the same role within a higher-level object.
			Role Addressing
				Addressing All Objects for a Role
				Addressing One Object for a Role
					Addressing One Object at Random
					Round-Robin Addressing
					Custom Addressing
		Owner Ordinalities
			No Owners
				An object without an owner is usually a memory leak as a side oeffect of a circular reference.
				If at all possible, objects should recognize and log a warning when they have been orphaned.
				If possible, objects should recognize and throw excpetions when too many are leaking.
			One Owner at a Time
				Creator
					An object's scope remains that of its creator for the object's lifetime.
				Factory
					One object creates new objects on behalf of another.
				Namespace
					An object is created within an object that allows it to be addressed by name.
					An object is created outside a namespace and is later registered with the namespace.
				Assembly Line
					An object is created to represent some multi-stage task.
					The object is passed from one worker to another.
					Each worker performs part of a larger complex task.
					The object represents a complete result when all stages are complete.
			Multiple Owners
				An object is created by one object and passed to one or more others.
				Multiple Serial Owners
					Each owner relinquishes ownership while passing the object to the next.
				Multiple Parallel Owners
					An object is created by one object and passed to one or more simultaneous users.
					Use must be coordinated from within the object being used.
					Users are not aware of each other.
		Owned Ordinalities
			Owns No Objects
			Owns One or More Objects
		Explicit Ownership
			This is Perl's standard ownership mechanism.
			Objects are stored in members of their owners.
			Objects are destroyed when their owners release them.
		Implicit Ownership
			About
				The base class tracks object ownership and parentage.
				Dynamic composition is simplified.
				Objects are permitted to self-destruct when they are finished.
				Objects are identified by their roles within their owners.
				The mechanism may be visualized as object-scoped namespaces.
			Implicit Ownership upon Creation
				Objects are assigned roles at construction time.
				The base class tracks owned objects by roles.
			Implicit Ownership upon Request
				Objects created without roles may be assigned roles later.
				The base class begins tracking these objects at the time of assignment.
				Unassinging roles may trigger destruction if the base class held the sole reference to these objects.
			Inspecting Implicitly Owned Objects
				Addressing Owned Objects
					Addressing owned objects by Role
					Addressing Owned Objects by Class
					Addressing a Single Owned Object
					Addressing Multiple Owned Objects
				Iterating Owned Objects
					Iterating owned objects by Role
					Iterating owned objects by Class
				Counting Owned Objects
					Counting Owned Objects by Role
					Counting Owned Objects by Class
		Benefits of Ownership
			Default response target.
			Role and type responses.
		Transferring Ownership
			Implicitly during storage.
				This is Perl's referencing model.
				Storing an object also implies sets ownership.
				Releasing an object relinquishes ownership.
				Easy to implement---just let Perl do it.
				Difficult to convey benefits without ability to introspect owner relationships.
			Explicitly via method.
				Explicit mechanisms are easier to understand.
				More work for users.
				More reliable---no need for Perl magic.
		Determining Ownership in Perl
			Examine the call stack via caller() in package DB.
			Have the framework call everything, all the time.
			Decorator that injects the current $self.
				Nick Perez suggested this.
				Custom decorators can be defined with Devel::Declare and MooseX::Declare.
				A simple C<< parent SomeObject->new() >> might deliver the necessary information.
				It's a little magicky, but it might be easier (and saner) than walking the call stack.
			MRO::Magic
				Nick Perez suggested this.
				Rjbs is working on it.
			It's not necessary to track all object ownership.
				Basic objects that don't use the framework don't need to be tracked.
	Service Composition
		Service Scope
			Available to One Object
				Generally pointless, since services are meant to be visible in wider scopes.
			Available to Multiple Objects
				It is ideal for a service to be available and useful for multiple objects.
				The service must coordinate requests internally.
					Objects cannot coordinate use of a service.
					This is common, so it must be part of a base service class.
			Available to No Objects
				Invisiblity is useless.
				A service must be visible to be used.
		Service Ownership
			A serice is owned by a single entity that exposes it to other objects.
			Other objects may not assume ownership of a service.
		Service Exposure
			Service Exposed Within One Process
			Service Exposed Internally and to Other Processes
			Service Exposed Only to Other Processes
		Service Creation
			Service Creation by Configuration
			Service Creation upon Request
			Service Creation Implicitly upon Need
		Service Destruction
			Service Destruction upon Request
				Graceful Shutdown
				Immediate Shutdown
			Service Destruction upon Container Destruction
			Global Destruction at Program Exit
Object Interaction Patterns
	Synchronous
		Call and Return
		Request and Wait for Reply
		Ordinalities
			One Call and One Request
	Asynchronous
		Request and Asynchronous Callback
			Callback by Function Reference
				Supports continuations.
				Supports quick, low-level code.
			Callback by Object or Class and Method Name
			Callback by Role and Response Type
		Promises
			Requests as Promise Factories
			Waiting for Promises
		Request Ordinalities
			No Requests
			One Request
			Multiple Requests
		Response Ordinalities
			No Responses
			One Response
			Multiple Responses
Task Patterns
	Task Lifespan
		Task Commencement
			Task Begins with Object Instantiation
			Task Begins upon Request Receipt
		Task Completion
			Task Ends upon Successful Completion
			Task Ends upon Exception
			Task Ends with Cancellation Request
			Task Ends with Object Shutdown
			Task Ends with Object Destruction
				Objects may be destroyed before they are finished.
				Global destruction is an extreme case.
				There may be a race between the task completion and object destruction.
				A user may knowingly cancel a task by destroying the object performing it.
			Task Never Ends
				Programs may halt without notification or opportunity to clean up.
				There's nothing to be done in these cases.
				If absolute reliability is required, try to minimize the amount of time when sudden halting can be catastrophic.
	Task Ordinality
		No Tasks Per Object
			An object may be created for a purpose that is not needed in a partucular execution.
			Optimally, the object would not be created until its task is required.
		One Task Per Object
		Multiple Tasks Per Object
			Tasks Performed Serially
			Tasks Performed in Limited Parallelism
			Tasks Performed without Parallelism Limit
Communication Patterns
	Terms
		Producer
			An object that produces information.
			Also known as a source.
			Might be a better name than "responder".
			POE::Wheel is a kind of producer.
			POE::Component::IRC is both a producer and a consumer.
		Consumer
			An object that consumes information from a producer.
			Also known as a sink.
			Objects may be both producers and consumers at the same time.
		Requester
			An object that initiates a transaction by making a request.
			Requests may be performed by sending messages to services.
			Some objects imply requests when they are created.
			Method calls are a form of request.
			Requesters produce requests.
			Requesters may consume responses.
		Responder
			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.
			All aliases are configured regardless whether a particular code path requires them.
		Lexical Alias Conflicts
			Multiple continuations may be active at once.
			They may have identical data members.
			Lexical variable names need to identify the continuations to which they refer.
			POE::Stage and Lexical::Persistence use prefixes to disambiguate continuations.
			The part of the variable name up to the first underscore identifies the continuation.
			The remaining variable name identifies the data member within the named continuation.
		Additional Conveniences
			$self may automatically be aliased to $_[0], Perl's conventional method parameter identifying the object.
			The "self" prefix may be aliased to members of $self.
			$args may be aliased to a hashref of method parameters, possibly kept in $_[1].
			Likewise, the "arg" prefix may be aliased to $args members.
Miscellaneous Ideas
	Metaphors
		Extending the Actor Metaphor
			Actor
				An object that can take requests and respond with results.
				Described as "services" elsewhere.
				May also be helper objects.
				POE::Session is a kind of actor, although not in the computer science sense of the word.
				POE::Wheel objects aren't actors because they don't stand alone.
				In this metaphor, actors don't include their own mailboxes, nor do they actively await messages.
			Prop
				Basic, non-actor helper objects.
				They may interact with messages, or use basic asynchronous callback facilities like timers.
				They generally perform very low-level work.
				Actors use them to fulfill their roles.
			Director
				The event loop, message router and dispatcher.
				May represent POE::Kernel within the metaphor.
			Stage
				About
					Isolated computational units.
					More like conventional actors.
					Ideally, stages should behave identically no matter what.
					In practice, each type of stage probably has its own caveats.
				Cooperative Stages
					Act as thin interfaces between POE::Kernel and actors.
					Don't have their their own mailboxes.
					Immediately and synchronously forward events to actors.
				Threaded Stages
					Act as bidirectional queues between POE::Kernel (which lives in the main thread) and the actors that coexist within a subthread.
					Contain their own mailboxes.
					Cannot directly call anything that exists in another stage.
					Other iThreads caveats apply.
				Forked Stages
					Act as bidirectional queues between POE::Kernel (which lives in the main process) and the actors that coexist within a child process.
					Contain their own mailboxes.
					Cannot directly call anything that exists in another stage.
					Other process-boundary caveats apply.
			Propmaster
				An ORM of some sort.
	DOM Namespaces
		XPath Object Addressing
			About
				Allows global addressing of objects through a DOM-like container and XPath-like queries.
				Proof of concept exists using XML::LibXML and actual DOM and XPath queries.
				Supports multiple-object addressing.
				Supports identifying objects by class, role, and other attributes.
				In a cluster, nodes may advertise their services by adding their DOMs to a directory.
				The directory can execute XPath queries that span the entire network.
			Caveats with XPath Object Addressing
				Robert Grimes pointed out that there is very little actual need for finding objects globally.
				Most objects interact locally.
					Parent object interacts with children.
					Children interact with parents.
					Children interact with siblings, usually through a moderator.
				Global addressing facilitates broken encapsulation.
				Global addressing should only be used for services.
			Javascript use of DOM Addressing
				Torsten Raudssus pointed out that Javascript uses DOM for similar purposes.
				Code may manipulate page elements singly or in groups by addressing them with XPath.
				It can be very convenient.
				This seems to be a subset of Robert Grimes' earlier point.
				Javascript is manipulating sibling objects within the same container---the page containing the code.
				In a larger application, it seems safer to limit each object's reach.
				What sorts of limitations are reasonable?
	Proxy Objects
		About
			Proxy objects are an alternative to services and explicit messages.
		Remote Object Type
			Remote Helper
			Remote Service
		Remote Object Existence
			Remote Object Already Exists
				The local proxy object connects to the remote object during instantiation or first use.
			Remote Object Created on Demand
				Creating the local proxy triggers creation of the corresponding remote object.
		Remote Process Existence
			Remote Process Already Exists
				The local proxy object connects to the remote process during instantiation or first use.
			Remote Process Created on Demand
				Remote processes are created as needed.
		Remote Class Existence
			Remote Process Has Required Class
				Remote objects are instantiated from remote copies of the requied class.
				Incompatible versions of the same class may cause problems.
			Remote Process Needs Required Class
				The local process may push a required class to the remote process.
				Dependencies may also need to be pushed.
				In some cases, tarballing the entire module suite may be needed.
				The remote process must have a version of Perl capable of executing the remote object.
				Injecting code into other processes or even other machines must be done securely.
				The remote process should cache the code to avoid additional performance issues.
				Alternatively, the remote process may install the required module from CPAN.
				Compiled modules have their own set of problems.
					Modules may need to be built on the destination machine to guarantee they work.
		Further Considerations
			Blocking Constructors
				Constructors are expected to return complete, usable objects.
				Remote procedure calls imply blocking until responses are ready.
				Promises can alleviate this somewhat.
					Promises are permitted to work in the background until their information is needed.
					They therefore block less than synchronous calls.
					However they may still block for significant amounts of time.
			Conserving TCP Sockets
				One implementation could use a TCP connection per remote object.
				TCP connection building and teardown are expensive.
				It will be more efficient to multiplex object communication between the same processes.
				The BXXP protocol seems designed for this task.
	Reflexive Data Members
		POE's early object environment experiments were very MUD-like.
		Nearly every object was required to be in a container.
		Changing an object's container required updates to its old and new containers' contents.
		This was a fundamental aspect of the system.
		The system implemented basic code to handle the referential integrity.
		Procedure
			Ask the object whether its container may be changed.
			Ask the old container whether the object may be removed.
			Ask the new container whether the object may be added.
			Move the object from its old container to its new container.
			Notify the old container that the object was removed.
			Notify the new container that the object was added.
			Notify the object that its container has changed.
Technology Questions
	How are new Moose types defined?
		New types may be needed for some of the container magic.
	How may hooks be affixed to Moose members?
		Attribute traits allow accessors and mutators to behave differently.
		Member change advertisement may be implemented as traits.
		Chris Williams suggested Variable::Magic as well.
	How does Moose map to this framework's features?
		Moose features seem to be coupled to classes rather than individual objects.
		How can Moose implement the basic functionality necessary for the features listed in this document?
