> Emits: connect_error(Error)
> Emits: read_error(Error)
> Emits: write_error(Error)
just a small comment. I hate to type so could we in general support 2 types
of the above declarations with the second being something more perlish like:
emits {
connect_error(Error)
read_error(Error)
write_error(Error)
}
or like the C++ public/private labels:
emits:
connect_error(Error)
read_error(Error)
write_error(Error)
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Sunday, August 11, 2002 4:29 PM
To: Rocco Caputo
Cc: [EMAIL PROTECTED]
Subject: Re: Object System: embedded documentation
On Fri, Aug 09, 2002 at 10:05:49PM -0400, Rocco Caputo wrote:
> On Fri, Aug 09, 2002 at 05:14:02PM -0500, Garrett Goebel wrote:
>
> > "public echo(Data)"
> >
> > means that the echo _method_ handles "Data" messages? but...
> >
> >
> > "Emits: echoed(Data)"
> >
> > means echoed _messages_ of type "Data" are sent?
> >
> > Seems like you're conflating the syntax of messages and methods... And
maybe
> > I'm just showing my ignorance, but I'm confused as to whether you're
talking
> > about "echo" messages, or "data" messages. And what it means for an
"echo"
> > message to be of type "data".
>
> It is quite possible that I am.
>
> First, the description and the sample markup is a little out of sync.
> It should be an "echoed" message in the commentary, to match
> echoed(Data) on the Emits line.
>
> I hope this revision is clearer:
>
> The "Emits:" directive specifies that this method will emit an
> ecohed(Data) message. This is a message named "echoed" of type Data.
> Messages are given unique names to describe their puproses and
> differentiate them from other messages of the same type. For example,
> a TCP client component may emit several messages of type Error. They
> would be difficult to tell apart without separate names.
>
> Emits: connect_error(Error)
> Emits: read_error(Error)
> Emits: write_error(Error)
I would like to see an approach that uses UML-style object associations.
This
has the advantage that you can group messages into interfaces and specify
which interface is used when talking to the various other objects that are
related to $self.
So, given that there is an interface ErrorMsg with the methods
connect_error,
read_error and write_error you would specify for $self that it is
associated to one object that has the ErrorMsg interface and that $self
calls
ErrorListener (the role name). Associations are like collections of pointers
to other objects, just at much higher level and with magic and checks
attached.
Event/message names are method names and have
always been treated like that. The mapping event name -> method can be
solved with an intermediate object that translates. If this should be used
often introducing a dedicated feature for this is easy.
>
> > Examples:
> > method echo
> > method echo()
> > method echo(DATA echo)
> > method echo(DATA echo) is public
> > method echo(DATA echo) is public : DATA echoer
> > method echo(DATA echo) is public : DATA echoer, DATA log
>
> I have added this just before "Shorthand Component Notation".
>
> As long as we're painting bikesheds, when would it be useful to omit
> the signature?
If it should be outside of the type system and its checks.
It should be possible to reference components without a signature. This
could
be uses to work with POE sessions or similar things. Receiving events from
these could be modeled by wrapping them into a message and delivering them
if the component has some Plain_Old_POE interface.
torvald
