is delegateTo "real" delegation?

I guess it would be possible to just enumerate all objects
involved, and
make them variation points. E.g. like you did with
delegateToMethod, you
basically make the method name a variation point. I guess
you could do
similar things by allowing to change arguments.

On the other hand, there are a number of implicit matters,
such as the
binding of self. In literature, this seems to decide whether
the process
is called delegation or rather consultation/message
forwarding.

Other implicit matters include evaluation context of
arguments for
example, but I'm not sure it's a good idea to allow this
to change,
unless it is made explicit, such as providing a parameter
exactly for
this purpose to performOn.

Imho, it would be confusing to just have 10 different kinds
of
delegation which just have a different name, because then
who is going
to remember which one does what?
Rather, I'd prefer having one or two options which are
well-known (e.g.
classic delegation, and message forwarding), and then have
one very
generic method which allows configuration of all variation
points, such
as method name, arguments, ...

Not sure what others think though...

Kind Regards,

Hans

On Tue, 23 May 2006 22:32:34 +1200
Quag <quaggygmail.com> wrote:

> Hi SainTiss,
> 
> On 5/23/06, SainTiss <saintissgmx.net> wrote:
> > Hi,
> >
> > Unless I misunderstand the concept, a crucial
property of PBL
> > delegation is the fact that "self" is
late bound, so that it points
> > to the object which initiates the delegation.
> > However, the delegateTo method on Call does not
take this into
> > account, since it basically just does a doMessage
call. Hence, self
> > will point to the object which has been delegated
to instead.
> 
> Yes. That was the intention behind the delegateTo
method. There are
> dozens of valid ways to do delegation in Io. delegateTo
implements the
> first one which I stumbled upon. I in no way claim that
it is the one
> true form of delegation, merely that it is one of many
which are used.
> 
> Over time as we identify other forms of delegation and
add them in, we
> can refactor the names. At the time I needed to pick a
name, and I
> didn't want to have to explore the other delegation
techniques before
> I could select a name for the one I needed.
> 
> I recently added delegateToMethod.
> 
>         delegateToMethod := method(target, methodName,
>                 target doMessage(self message clone
setNext
> setAttached setName(methodName), self sender)
>         )
> 
> SainTiss, could you help me identify all the different
strange and
> unusual forms of delegation used in Io? At some point I
was planning
> on having a hunt through lots of io code  and finding
all the
> different delegation tricks that people get up to.
> 
> Jonathan.
> 
> 
> ------------------------ Yahoo! Groups Sponsor
> --------------------~-->  You can search right from
your browser? It's
> easy and it's free.  See how.
> http://us.click.yahoo.com/_7bhrC/NGxNAA/yQLSAA/saFolB/TM

>
------------------------------------------------------------
--------~
> -> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 


-- 
A liberal is a person whose interests aren't at stake at
the moment
  -- Willis Player

Hans Schippers
Research Assistant of the Research Foundation - Flanders
(FWO -
Vlaanderen)
http://www.win.ua.a
c.be/~hschipp/
Formal Techniques in Software Engineering (FoTS)
University of Antwerp
Middelheimlaan 1
2020 Antwerpen - Belgium
Phone: +32 3 265 38 71
Fax: +32 3 265 37 77

Not sure if this will be considered adequate, but this would
be a
possible implementation for delegation with late self
binding, and
renaming the previous one to forwardTo:

Call forwardTo := Call getSlot("delegateTo")
clone

Call delegateTo := method(target, altSender,
  slot := target getSlot(self message name)
  if (getSlot("slot") type ==
"Block",
    getSlot("slot") performOn(call sender,
altSender ifNilEval(self
sender), self message)    , // else
    doMessage(call message clone
setName("forwardTo") setAttached
setNext, call sender)  )
)

Cheers,

Hans

On Tue, 23 May 2006 13:26:27 +0200
SainTiss <saintissgmx.net> wrote:

> I guess it would be possible to just enumerate all
objects involved,
> and make them variation points. E.g. like you did with
> delegateToMethod, you basically make the method name a
variation
> point. I guess you could do similar things by allowing
to change
> arguments.
> 
> On the other hand, there are a number of implicit
matters, such as the
> binding of self. In literature, this seems to decide
whether the
> process is called delegation or rather
consultation/message
> forwarding.
> 
> Other implicit matters include evaluation context of
arguments for
> example, but I'm not sure it's a good idea to allow
this to change,
> unless it is made explicit, such as providing a
parameter exactly for
> this purpose to performOn.
> 
> Imho, it would be confusing to just have 10 different
kinds of
> delegation which just have a different name, because
then who is going
> to remember which one does what?
> Rather, I'd prefer having one or two options which are
well-known
> (e.g. classic delegation, and message forwarding), and
then have one
> very generic method which allows configuration of all
variation
> points, such as method name, arguments, ...
> 
> Not sure what others think though...
> 
> Kind Regards,
> 
> Hans
> 
> On Tue, 23 May 2006 22:32:34 +1200
> Quag <quaggygmail.com> wrote:
> 
> > Hi SainTiss,
> > 
> > On 5/23/06, SainTiss <saintissgmx.net> wrote:
> > > Hi,
> > >
> > > Unless I misunderstand the concept, a crucial
property of PBL
> > > delegation is the fact that
"self" is late bound, so that it
> > > points to the object which initiates the
delegation.
> > > However, the delegateTo method on Call does
not take this into
> > > account, since it basically just does a
doMessage call. Hence,
> > > self will point to the object which has been
delegated to instead.
> > 
> > Yes. That was the intention behind the delegateTo
method. There are
> > dozens of valid ways to do delegation in Io.
delegateTo implements
> > the first one which I stumbled upon. I in no way
claim that it is
> > the one true form of delegation, merely that it is
one of many which
> > are used.
> > 
> > Over time as we identify other forms of delegation
and add them in,
> > we can refactor the names. At the time I needed to
pick a name, and
> > I didn't want to have to explore the other
delegation techniques
> > before I could select a name for the one I needed.
> > 
> > I recently added delegateToMethod.
> > 
> >         delegateToMethod := method(target,
methodName,
> >                 target doMessage(self message
clone setNext
> > setAttached setName(methodName), self sender)
> >         )
> > 
> > SainTiss, could you help me identify all the
different strange and
> > unusual forms of delegation used in Io? At some
point I was planning
> > on having a hunt through lots of io code  and
finding all the
> > different delegation tricks that people get up to.
> > 
> > Jonathan.
> > 
> > 
> > ------------------------ Yahoo! Groups Sponsor
> > --------------------~-->  You can search right
from your browser?
> > It's easy and it's free.  See how.
> > http://us.click.yahoo.com/_7bhrC/NGxNAA/yQLSAA/saFolB/TM

> >
------------------------------------------------------------
-------
> > -~ -> 
> > 
> >  
> > Yahoo! Groups Links
> > 
> > 
> > 
> >  
> > 
> > 
> 
> 
> -- 
> A liberal is a person whose interests aren't at stake
at the moment
>   -- Willis Player
> 
> Hans Schippers
> Research Assistant of the Research Foundation -
Flanders (FWO -
> Vlaanderen)
> http://www.win.ua.a
c.be/~hschipp/
> Formal Techniques in Software Engineering (FoTS)
> University of Antwerp
> Middelheimlaan 1
> 2020 Antwerpen - Belgium
> Phone: +32 3 265 38 71
> Fax: +32 3 265 37 77


-- 
A liberal is a person whose interests aren't at stake at
the moment
  -- Willis Player

Hans Schippers
Research Assistant of the Research Foundation - Flanders
(FWO -
Vlaanderen)
http://www.win.ua.a
c.be/~hschipp/
Formal Techniques in Software Engineering (FoTS)
University of Antwerp
Middelheimlaan 1
2020 Antwerpen - Belgium
Phone: +32 3 265 38 71
Fax: +32 3 265 37 77