Re: Bracekets
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?
Interesting, we don't have the typeglob anymore, so there isn't the
question of:
*typeglob[$index] = $value;
being either an array or a hash. The real problem, is the lack of
visual indication of what's going on. Try:
array[ %hash{$key} ]
without braces looks like:
array[ %hash[$key] ]
Now, the behaviour of array indicies and hash keys is different too.
For example, for an array these are equal (or are they?):
array[1], array[1]
but obviously, in a hash these aren't:
%array[1], %array[1]
but wait, there's more... what does:
multi_dim[$a][$b][$c]
give?
I leave this challenge to Luke :)
Jonathan Paton
__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
Re: Bracekets
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 matrix class, where it's better implemented as a hashtable than an array. Users of the matrix wouldn't need to know the difference. But that's a rather tenous argument at best. Mike Lambert
Re: Bracekets
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 matrix class, where it's better implemented as a hashtable than an array. Users of the matrix wouldn't need to know the difference. But that's a rather tenous argument at best. Interesting application. Could a tied array intercept multidimensional calls? E.g. tie matrix, 'MATRIX::SPARSE', 3; allow the MATRIX::SPARSE object to intercept indicies up to 3 deep? Jonathan Paton __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
Re: Bracekets
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 possession of a rich syntax must be in need of a rewrite. -- Jane Austen?
Re: Unary dot
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 }
Piers }
You could use the Smalltalk way by defining method myself in UNIVERSAL,
which simply returns self. So .myself would always be yourself,
which you could store if needed.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Ex4 smart match question
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 intersection (i.e. do they share one or more element value?)
That choice facilitates:
given data {
when looking_for_one_of_these {...}
when or_else_one_of_these {...}
...
}
%left =~ %right
Hash key intersection (i.e. do they share one or more keys)?
This is really set intersection, if you use the common perl idiom
of hash keys as implementing a set.
Incidentally, the table of C=~ comparisons (Table 1) at:
http://dev.perl.org/perl6/apocalypse/4
suggests that hash/hash matching is equivalent to:
match if grep exists $a{$_}, $b.keys
I hope to convince Larry that it would be better if it were equivalent to:
match if any($a.keys) =~ any($b.keys)
so that each key is recursively C=~-matched against each key.
I'd prefer that because if I hope to convince Larry to allow hash
keys to be any scalar value (not just strings). That way the
keys as a set idiom might actually be usable.
One can imagine useful default interpretations that are not commutative.
Certainly. But they'd also be that much harder to remember (and predict).
Damian
Re: Unary dot
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:
method ical {
given _[0].ology {
... { _[0].ish }
}
}
It would be nice to have a cleaner way to do that, though.
So I'd like to see something like your pragma. However, I'd
probably make it more like:
use invocant 'self';
method ical {
given self.ology {
... { self.ish }
}
}
and then probably use:
use invocant 'me';
to save those two extra characters!
;-)
Damian
Re: Unary dot
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're not using explicit parameters, you can always write:
method ical {
given @_[0].ology {
... { @_[0].ish }
}
}
It would be nice to have a cleaner way to do that, though.
So I'd like to see something like your pragma. However, I'd
probably make it more like:
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.
--
Piers
It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
-- Jane Austen?
Re: Unary dot
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
- and .
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 used for actual object method calls.
From C++'s point of view, there is really no need for two different
operators (one for pointers and the other for stack allocated). However,
the reason is primarily historical as it adopted the syntax from C.
Nevertheless, C++ benefits from this syntax becuase it allows things to
overload the - operator thereby allowing smart pointers and such while the
.. operator cannot be overloaded to ensure correct binding semantics.
I was wondering if Perl6 could take advantage of this type of idea and have
some sort of way to overload operator .
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.
The problem then is when you call a method or access a data member inside
operator . then it becomes infinitely recursive. Nevertheless it would be
really nice if this type of functionality could be achieved fairly simply.
Any ideas?
Tanton
Re: - and .
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 is
overriding functions to do other stuff before, after, or both before and
after, a function, then aspects should be enough for you. Check out
Aspects on CPAN for a Perl 5 implementation, or the AspectJ stuff for the
original (at least, I think it was the first) definitive source for this
kind of stuff.
Of course, overloading and/or changing the way certain operators work
should be fair game in Perl6 along with the rest of the grammar. But I'm
just pointing out that this other solution will solve your recursiveness
problem, and is doable today, in Perl 5. It's also a much nicer interface
to this kind of programming. :)
Mike Lambert
