On Fri, Aug 09, 2002 at 11:22:05PM -0600, Chris Fedde wrote:
>
> First: Are you abandoning plain perl? Will POE become a preprocessor
> that chews on both code and pod/markup segments to build the final
> system? I'm not sure I like that idea much. I enjoy a clean
> separation between doc and code. Even when they are intermixed in the same
> file.
I would like to avoid preprocessing if at all possible. Even source
filters cause problems with some people-- especially those who want to
deploy programs using perlapp or perl2exe. I think I would start over
if it came to that.
POE and tools working with components will need information that Perl
just doesn't provide.
Is a method public or private?
What type of message does it expect to receive?
What types of messages will it emit?
Should the return value be considered a response message? If so,
what type of message?
Is the function written for POE or traditional?
I originally considered keeping this information in a package or
C<our> variable. It would work much the same as @ISA does, only it
would be more involved.
our %methods =
( echo => [ PUBLIC, "Data" ]
);
our %events =
( echoed => "Data"
);
These amount to the component's public interface(s). As public
aspects of a component, they would need to be documented. Since
everyone should be documenting their public interfaces anyway, I
decided it would be best that the document also be the description
that POE reads.
Based on what Skrewtape showed me, the description can be in POD and
in Perl at the same time. Translating the human readable language
into data for POE is possible at load time.
So far this has nothing to do with code generation or system modeling.
It's just a way to tell POE which methods are public, which are
private, and so on.
> Second: Maybe I am misreading things a bit. It appears that the actual
> level of abstraction in this system is not much higher than exists for the
> current PoCo set of packages. I was hoping for something much higher
> level that hides the event mapping and passing details:
>
> package Echo;
> use POE::Object qw( Server::TCP );
> my @ISA = qw( POE::Object::Server::TCP );
>
> sub Start {
> my $self = shift;
>
> $self->Hash(_listen => SUPER->new(
> Address => 'localhost',
> Port => '10101',
> ));
>
> $poe_root_object->Register($self);
> }
>
> #
> # Take advantage of well chosen default methods for all
> # of POE::Object::Server::TCP except the Input method
> #
>
> sub Input {
> my $self = shift;
> $self->Output( $self->Data );
> }
>
> package main;
> $poe_root_object->run();
You bring up an interesting question in passing. What should POE's
components be called? POE::Component, POE::Class, POE::Object?
Your idea has the benefit of being closer to unadorned Perl than POE.
It needs to address composite components and other things, though.
For example, my proposal outlines a system where an Echoer object and
a TCP server object can be combined into a TCP server. This allows
the Echoer to be reused for other types of server (perhaps UDP and
UNIX sockets). And it obviously lets the TCP server be reused for
other protocols.
If you can solve that and the other issues in your proposal, I would
consider it over my own. A simpler yet still complete design is
favoriable.
> Third: I think that the implementation is orthogonal to any
> code generation schemes. Maybe a good XSLT guy can write a
> style sheet that translates XMLized UML into a Perl
> code template.
I agree. POE shouldn't care how the code is generated as long as all
the information it needs is present.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sf.net
