> I could see something like:
>
> method operator.( $self: $function ) {
> if( $function eq "inc" ) { ++%self.funcount{$_[2]}; }
> else { $self.inc( $function ) }
> }
>
> That would count how many times you called each function.
Sounds a lot like aspect-oriented programming. If what you want
Since Perl is changing from -> to . (a change I welcome). It might be
interesting to ask ourselves if there is any benefit from langauges like C++
or OCL that use both the -> and the .
>From OCL's point of view the -> is used for "meta" level things such as
iterations over collections. The . is
> > use invocant 'self';
>
> *Much* better name. You see, that's why you're the mad genius and I'm
> just the lowly lab assistant. Marthter.
And, given that I'm jutht Larry'th lowly lab aththithtant, that would
theem to make you a meta-Igor!
%-)
Damian
Damian Conway <[EMAIL PROTECTED]> writes:
> Piers asked:
>
>> So, is there any chance that we'll be able to do:
>>
>> class ical {
>> use object_name '$self';
>>
>> method ical {
>> given $self.ology {
>> ... { $self.ish }
>> }
>> }
>> }
>
> Of course, if you
Piers asked:
> So, is there any chance that we'll be able to do:
>
> class ical {
> use object_name '$self';
>
> method ical {
> given $self.ology {
> ... { $self.ish }
> }
> }
> }
Of course, if you're not using explicit parameters, you can always write:
Peter Scott asked:
> Why give up the chance to let things that look different behave differently?
Because then you'd have to remember which order did what.
Forcing you to actually think and remember is very unDWIMical. ;-)
> What do [the following do]?
>
> @left =~ @right
Array int
> "Piers" == Piers Cawley <[EMAIL PROTECTED]> writes:
Piers> So, is there any chance that we'll be able to do:
Piers> class ical {
Piers> use object_name '$self';
Piers> method ical {
Piers> given $self.ology {
Piers> ... { $self.ish }
Piers> }
Piers> }
P
"Jonathan E. Paton" <[EMAIL PROTECTED]> writes:
> but wait, there's more... what does:
>
> @multi_dim[$a][$b][$c]
>
> give?
Who cares? So long as the intermediate results in
@multi_dim.[$a].[$b].[$c] respond to [].
--
Piers
"It is a truth universally acknowledged that a language in
poss
> > but wait, there's more... what does:
> >
> > @multi_dim[$a][$b][$c]
> >
> > give?
>
> It's representation hiding. I can change my layout from hashes to arrays
> without the clients of my code having to know. :)
>
> Seriously, the above argument might actually hold some merit when changing
>
> but wait, there's more... what does:
>
> @multi_dim[$a][$b][$c]
>
> give?
It's representation hiding. I can change my layout from hashes to arrays
without the clients of my code having to know. :)
Seriously, the above argument might actually hold some merit when changing
a matrix to a sparse m
> I know this is going pretty far back in the design process, but I was
> wondering why we're using curlies for hash subscripts, now that the %
> sticks around when you key it. Then curlies could only two
> things : Anonymous hash making and closure making. Maybe it's just too
> much culture s
I know this is going pretty far back in the design process, but I was
wondering why we're using curlies for hash subscripts, now that the %
sticks around when you key it. Then curlies could only two
things : Anonymous hash making and closure making. Maybe it's just too
much culture shock?
I'v
12 matches
Mail list logo
