hi,
as this seems to show POE's future, I'd like to add that I've been thinking
about writing an Object Layer for POE. Note that although I use this term it
is probably not similar to Rocco's object layer. But I have just seen some code
that was more centered around some kind of object repository and an
attached curator, so it would be possible that it is supposed to go in the
same direction.
Motivations for writing one:
-POE now is fine but isn't as good for bigger applications
-according to Rocco additional features should be seperate from POE Kernel
etc. (and I agree)
-keeping associations between objects with the means of aliases and postbacks
works but is hard to manage if object associations grow in amount and
complexity
-some things as exceptions would need some basic behaviour not yet included
in POE
-many features requested for IKC are useful for non-distributed programs
Aims:
-starting from the design one should be able to easily take the design specs
(transform them to some poe form) and just write object methods without
having to touch anything regarding inter-object communication
-this includes:
-associations are specified for the object and it can only communicate
through them, no more global aliases
-maybe some object interface descriptions
-associations need intelligence, so that fail-over, failure handling etc.
work, an adaptor written as a real POE-Object is too much, but
distributed programs need more features (this must work with poe garbage
collection! and will make it easier if done right)
-nested namespaces for objects
-powerful namespace features, merging namespaces, some kind of mapping/linking
(between) them, everything that is needed
-support for object containers (component framework), though not just as
nested / private namespaces but including support for pooling, migration,
component repositories
-I'd like to use standard Perl objects, not an own framework
-configuration/deployment/putting together POE apps and components:
-with the above available, one should be able to easily merge several
objects and maybe do the design, attach available implementations to
objects/acteurs, write/configure some adaptors everything is done ...
this especially applies to distributed apps, where one need to specify
which part should run where and which computing nodes could connect
(->stem ... ?)
-supply implementations for several design patterns: if we stick to "design
dominance" better use it properly and save a lot of time
-proper automatons or other ways to make running protocols easier (just set
up an program flow, interaction diagrams, ... and not hide it in code)
at least i think that NFA doesn't work right now, and state diagrams as in
NFA should be attached to particular roles/interfaces of an object so a
single object can (and often it has to) run several things with independent
flows
-probably a new session type, it should be possible to "attach" certain
behaviour like persistence to objects, maybe even without support by the
developer (modify behaviour during deployment/configuration))
overall, if the design is not hidden in code as it is with current (POE)
programs there can be a lot more magic and it is much easier and more
comfortable for developers. so i'd like to transfer as much from design as
possible, constrains, roles and things like that would be really good ...
POE as base already abstracts object communication to events and properly
encapsulates objects in their runtime context, a lot of good things can
be built atop of it...
til mid july i will not have any time to really work on it or just even
provide a detailed description (in contrast to the short notes above. but
there certainly are more details and implementation plans in my mind.
And I guess I forget several things ... :)
I'd like to know what other people think about this topic and an organized
development is probably better ...
Torvald
