Simon Cozens wrote:
> [EMAIL PROTECTED] (Deborah Ariel Pickett) writes:
> > That works, with one big proviso. You have to have predeclared all
> > possible methods in the class to which the object belongs, AND each
> > method in that class (and all defined subclasses) has to have a unique
> > signature.
Oh boy, that was badly worded on my part. Still, I hope I got my point
across that having same-method-name, different-signatures is Bad from
the perspective of havving DWIM bracketing.
> No! No, no, no! You're missing the beauty of runtime dispatch. Because
> the method will be located at runtime, you only need that particular method
> (which ever class in may happen to be in) to know how many arguments it
> wants, (which I think was stipulated in Damian's message but I could be
> mistaken) and it can all be resolved at run time. If you keep around the
^^^^^^^^^^^^^^^^^^^^^^
> n possible parses. Which you can do. It just shortens Dan's lifespan.
^^^^^^^^^^^^^^^^^^
About this point was when my brain when "a ha!". But I'm not yet
convinced that generating all possible parses is (a) of sane time
complexity, and (b) a little *too* DWIM for its own good.
> > class B {
> > method bar($x, $y) {
> > method bar($z) { # note 1
> Oh, bringing in multimethods Just Isn't Fair.
Those are multimethods? Migod, I feel like a person who's just
discovered for the first time in their life that the plate that gets
passed around in church is for putting money *onto*.
(Seriously, my OO is heavily C++-influenced, so I just think of the
above as function overloading. I thought multimethods existed in a sort
of parallel universe to regular class-and-method hierarchies, like
friend functions done right.)
(And where did my "note 1" go in my original email? Perhaps it had all
the answers I was looking for.)
> > I'm uneasy about how the whole parentheses thing sits when multimethods
> > are brought into the equation, but then I'm uneasy about multimethods in
> > the first place. I don't mind if people practise that kind of thing in
> > the privacy of their own homes, but not out in public, please.
> Well, you know, you brought them up, you get to mop away the issue.
Lucky me.
Let's try and be pragmatic[*] here. If we stick to the following
subset of the problem space:
- no multimethods
- all method signatures known through predeclaration
- no method name has two different signatures in the same class hierarchy
(all of which can be determined at compile-time), then there should only
be one possible legal parsing for any particular method call or
pipeline of method calls. Yes, the ACTUAL methods called may not be
knowable at compile time (due to polymorphism), but at least the syntax
tree has only one valid shape. Personally I think that this subset
forms the vast majority of normal OO designs, in any case.
Can we dictate that parentheses are optional in this case, and demand
parentheses in all others? Would that make everyone happy? (Except
multimethod freaks, but then, I've already said enough about you (or is
that "us"?).)
[*] Tough on a list like this, I know, but bear with me.
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
"My words, your expression. My land, always your possession. My song, your
production. My expense is always your deduction." - _You Don't Believe_, The
Alan Parsons Project
