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