On Sat, 2005-05-14 at 22:06 +1000, Damian Conway wrote:
> Luke wrote:
>
> > If the alternatives are:
> >
> > * declare $self, use $self.method, and .method for calling on $_
> > * use .method, and use $_.method for calling on $_
> >
> > I'd say the former has no case.
>
> I, for one, am not nearly so certain of that.
Well, there are many more alternatives (though I vastly prefer the
latter from the above). Here are some:
* Reverse-auto-accessors. That is, for any method, there is a
corresponding attribute whose value is (given that there is no
attribute declared, which would obscure it) a reference to the
method. These attributes are fictions, and only accessible from
inside the class, but from within, that gives you the ability to
call "$.method(...)" without breaking the syntax at all.
However, I'm assuming here that multi-methods exist as a single
method (i.e. you can have a reference to all at once), and
dereferencing goes through the normal signature matching.
* Create a default invocant variable that's easier to type than $?
SELF (ulch, tainted meat!) like "$$" (since $*PID replaces it);
"$." (Larry didn't like that because of "$..method", though; or
$, (which is nice because $,.method is fairly easy to type); or
what about an identifier name like "$me"? I'd prefer "$no", but
a) it's wrong to English speakers and b) "wa" got shot down
before ;-)
* Have an invocation operator that defaults to the current
invocant other than ^. Things that come to mind are "do method
(...)", "go method(...)", or "to method(...)"
* Have a pragma for .method meaning $?SELF.method so tha the
programmer can choose, such as "use method :on_invocant" or "use
method :invocant"
> for @clients {
> my $value = .volume * .rate;
> my $cost = .management_ratio * .volume;
> .add_profit($value - $cost);
> .gen_report()
> }
I like the look of that, and the way things stand now, people will write
that and it will work, but then they'll be shocked when they put in a
loop or given and it stops working inside the scope that contains a $_
that's not the invocant.
I think keeping $_ procedural and having "." favor OO is a smarter idea
than not, but that's just me.
> Calling lots of methods from within another method just isn't a frequent
> requirement...and if it is, it's usually isolated to one or two high
> level methods within a class. Especially when your language gives you
> dot-variables to access your attributes [...]
This sounds like a vote for reverse-auto-accessors....
> Furthermore, all my experience of *general* programming suggests that OO
> programming is only one choice of code structure, and not even the most
> widely applicable or appropriate one, especially when your language offers
> good support for procedural and functional programming approaches.
I agree. However, I don't like how surprising all of this will be for
the OO crowd. Make OO one option of many, sure, but don't make it hard
to cope with.
