Re: New PoCo Guidelines

[Andrew V . Purshottam]

Suggested standard for component documentation: describe the session
 structure created by the component, and in particular describe in 
 which session each callback coderef is evaluated. I had some small
adventures with PoCo::Server::TCP until I understaoond exactly what
session it created and what callbacks were evaled where.

Another suggestion: have standards for passing state down though a
component constructor. Perhaps follow the conventions of
PoCo::Server::TCP ?

Appologies if these are silly, I am just starting to write PoCos.
Andy

Re: New PoCo Guidelines

[philip]

On 26-Jul-2004 sungo wrote:
 On (07/25 16:56), David Davis wrote:
 
 -call conventions (use hashrefs instead of arrays?)
 
 are you talking about the insides of a component object? if so, don't
 meddle there. any guidelines for components really need to stick to
 interface alone. let the components do what is necessary to get their
 jobs done. 

I was the one who proposed talking about PoCo guidelines.  I came to this
conclusion after playing with PoCo::Server::HTTPD and PoCo::Child.  The
doco for both is thin. PoCo::HTTPD doesn't allow post-backs.  PoCo::Child
has the strangely named parm Alias, which doesn't set the alias of the
component but the alias of the session postbacks are posted to.  Things
like this made me that there had to be a better way.


No, I don't think the guidelines should dictate internal component
implementation.  With one exception : if you are doing OO and want people
to overload your component, then following a standard object model would
be nice.

Actually, 2 exceptions, if/when we agree on a standard, it would be nice
to implement POE::Component::Base which would help in conforming to the
standard.  In that case, internals would be dictated by that component. 
Mind you, there could also be POE::Component::Helper which would export
subroutines that did some of the dirty work to help non-OO implementations
conform.

-Philip

RE: New PoCo Guidelines

[Erick Calder]

 The doco for both is thin.

:( I thought I did a pretty decent job at doc for ::Child... if you have any
suggestions I'd be happy to consider them.

 PoCo::Child has the strangely named parm Alias, which doesn't
 set the alias of the component but the alias of the session
 postbacks are posted to.

why would you want to set the alias of the component's internal session when
you are never going to address it? and what's strange about naming it
alias?  what would you name it?

 POE::Component::Base

I love it.  and now that we're talking about this, could we shorten the base
name?  I have components like POE::Component::Player::Mp3 - which is
entirely too long!  Could we at least do POE::Co?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 28, 2004 9:44 AM
To: sungo
Cc: [EMAIL PROTECTED]
Subject: Re: New PoCo Guidelines



On 26-Jul-2004 sungo wrote:
 On (07/25 16:56), David Davis wrote:

 -call conventions (use hashrefs instead of arrays?)

 are you talking about the insides of a component object? if so, don't
 meddle there. any guidelines for components really need to stick to
 interface alone. let the components do what is necessary to get their
 jobs done.

I was the one who proposed talking about PoCo guidelines.  I came to this
conclusion after playing with PoCo::Server::HTTPD and PoCo::Child.  The
doco for both is thin. PoCo::HTTPD doesn't allow post-backs.  PoCo::Child
has the strangely named parm Alias, which doesn't set the alias of the
component but the alias of the session postbacks are posted to.  Things
like this made me that there had to be a better way.


No, I don't think the guidelines should dictate internal component
implementation.  With one exception : if you are doing OO and want people
to overload your component, then following a standard object model would
be nice.

Actually, 2 exceptions, if/when we agree on a standard, it would be nice
to implement POE::Component::Base which would help in conforming to the
standard.  In that case, internals would be dictated by that component.
Mind you, there could also be POE::Component::Helper which would export
subroutines that did some of the dirty work to help non-OO implementations
conform.

-Philip