Re: [Sooc-devel] Message handlers, interfaces

[Dan R. <sta...@gm...>]

Mike,

Alright, so I actually looked at the code for SCloneable, and now I
understand what you're talking about.  The idea behind these default
implementations is to allow messages to, by default, depend on other
messages.  One application, as you have demonstrated, is to minimize the
number of messages an "implementor" actually needs to handle.  As you
explained before, all an object has to do to be fully cloneable is handle
the "distinguish" method.  The default handlers in the SCloneable interface
take care of the various types of cloning.  This is possible because the
default handlers work with the memory directly without depending on the
specifc methods or variables of a given object.

So, this default implementation concept will work as long as the programmer
is broad enough when writing them.  It definitely works for SCloneable.  I'd
be a little nervous for other custom-made interfaces.  One problem I can
foresee is how this technique might encourages a programmer to lock an
interface to a particular class hierarchy.  In other words, a programmer may
feel encouraged to create an interface with default handlers written in
terms of SClock, expecting this interface to only be used for SClock and its
children.  This is sloppy programming of course, since it would make more
sense to include Clock-specific code in SClock itself.  Still, the
programmer could abuse the interface system in this way if he/she wanted.
This sort of interface-locking seems to border on multiple inheritance in
the way it could force an interface to actually be part of the inheritance
tree (albeit a very strange sort of branch).

Okay, on second thought, it's not really locking.  I neglected to consider
the fact that the programmer has the option of implementing his own handlers
for any message that has a default behavior.  So, no matter what, an
interface cannot be locked to a specific portion of the inheritance tree.
Still, this doesn't change the fact that an interface can function,  by
default, as part of that tree.  I'm not exactly sure what I think of this.

Interfaces are very safe in Java in that they are merely frameworks.  An
interface will only be functional if a programmer makes sure to implement
every piece of it.  The programmer never has to think about what the
interface will do if he chooses not to implement various pieces because it
is simply useless in that state.  In sooc, the programmer needs (or at least
ought) to know how a particular interface behaves by default.  He/she can
change this behavior to suit his/her needs, but this is an extra decision
that needs to be made each time an interface is implemented.  And it becomes
more confusing, I think, when the defaults don't assume SObject and only
methods/messages associated with SObject.

In any case, I'm not necessarily saying that what you've created is a bad
idea.  It's obviously relatively powerful in that you can essentially give a
whole bunch of new functions to an object just by handling one message.  I'm
just wondering if what we have here is really that clean.

In the case of SClone, SObject itself could implement the SCloneable
messages in a manner identical to the current defaults.  On the surface,
this would result in the same functionality.  Users would still only have to
"override" the distinguish message in order to make deep clones work for a
specific kind of child.

In this model, interfaces remain simply frameworks, as in Java.  It is up to
various branches of the class hierarchy to determine the default behavior of
an interface.  And if there is a behavior that really ought to apply
to allobjects, then it can simply be hard-coded into SObject.
Children can still
override these behaviors if required.  The point is, the interface is free
to remain a specification rather than a "suggested implementation," if you
will.

I wonder if it might be more in the spirit of sooc to limit default
behaviors to class definitions.  This way, a programmer is not encouraged to
tie some behavior to the interface definition and then forget months later
where it is indicated that Clocks should behave a certain way when the
Strokeable::stroke message is called and GolfClubs seem to not understand
how to do it by default (and, in fact, freak out because a Clock stroke has
nothing to do with a golf stroke).  (Srokeable is, of course, a horrible use
of interfaces, but I think it helps explain my point.)

Hopefully, I'm not grossly misunderstanding something here.  So just take
this as food for thought and eventually let me know what you think.

--Dan

P.S. Golfing should always be less dependent on time...



On 9/2/07, Dan Reinish <sta...@gm...> wrote:
>
> I'm sorry...i'm a little confused by your explanation.
>
> On 9/2/07, Mike Richman <mik...@gm... > wrote:
> >
> > The thing about messages is that they are totally dynamic: you
> > generally connect them in s_class_implement() or its brethren, but you
> > can (re)connect them anywhere in the class implementation.  So it
> > seems to me that checking that all the messages are connected needs to
> > be dynamic also.
> >
> > Regarding default implementations...  some of an interface's default
> > handlers can operate in terms of other messages (which may or may not
> > have default handlers) of the same or of inherited interfaces.
> > SCloneable /does/ assume that it's dealing with an SObject, but I feel
> > like that's valid.  Let me know if/why you disagree.
> >
> > -Mike
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a browser.
> > Download your FREE copy of Splunk now >>  http://get.splunk.com/
> > _______________________________________________
> > Sooc-devel mailing list
> > Soo...@li...
> > https://lists.sourceforge.net/lists/listinfo/sooc-devel
> >
>
>