Re: [TCLCORE] Pre-CFV - TIP#257,#279

[<ju...@pr...>]

> > I think, Neil was referring to the conceptual similarities between =
an=20
> > object (as in xotcl) and an ensemble, which are lost in current 257.
> >=20
> > Does the oo core language really need object specific procs?
>=20
> This is an important point.
>=20
> While I started out with a goal of implementing methods using normal
> commands, I eventually decided to not do this on the grounds that the
> natural C API signature for a method was not the same as the natural C
> API signature for a command. Instead, methods take an extra parameter
> that specifies the object invokation context (that contains the sort =
of
> thing you'd find out with [self]). The alternatives are to push an =
extra
> stack frame to hold it (which is visible to [upvar] and [uplevel], and
> slows down method invokation quite a bit), place the data in the
> interpreter (maybe you can make the recursive case or the case with
> [upvar]/[uplevel] work right here, but I don't want to have to try to
> figure it out!) or to stash it in an extra hidden argument (this is =
what
> I tried first, actually, but it's ugly). Coupled with a little bit of
> call-frame hacking, this has allowed me to make method invokation,
> especially of deep and complex inheritance hierarchies, very fast and
> easy to use. In particular, people writing methods can treat them just
> like normal procedure calls, and do not need to do anything with [self
> callinglevel] to see the caller.
>=20
> In short, introducing the new "method" stuff make life easier. It =
makes
> the code cleaner, and it makes the _use_ of the code cleaner too; it's
> the second part that makes it really worthwhile. It also makes method
> invokation faster, which isn't a bad thing. :-)
>=20
> Donal.


>Instead, methods take an extra parameter
> that specifies the object invokation context (that contains the sort =
of
> thing you'd find out with [self]).

What I've seen referred to as the 'invocant'.
Is this 'object invocation context' assumed to involve the context of =
just one object?

Whilst I'm not yet sure how these method/proc thingies will operate - =
can you please consider if it makes sense to accept multiple invocants =
for oo systems that may like to use this feature?

ie some oo extension may want to invoke a method in the context of more =
than one object at once.
see http://en.wikipedia.org/wiki/Multimethods

This isn't really a specific request I guess.. just a nudge towards =
generalization of the invocant/dispatch stuff if it happens to make =
sense.

I've been toying with the idea of multiple dispatch for my own oo system =
- but never came up with anything concrete.

Julian