Nathan Torkington wrote:
# making this part up
struct Person = [ qw(Name Age Height Weight) ];
# but once you have a named structure, you can say ...
my Person %nat;
with (%nat) {
$Name = "Nathan"; # rewritten to $nat{Name} at compile-time
...
}
It's kinda like
Markus Peter wrote:
... then I run into trouble
if the method author does not even know wether its procedural or OO.
What I wrote is dependent on an environmnet where the Cmethod keyword
is used to write methods that are distinct from subroutines, and
also, a Csub with the same name could
Piers Cawley wrote:
In my opinion the contents of $ME should allow to determine wether it was
called as a procedure or as a method, the easiest way to do that is undef
for procedure, object for method and classname for class methods.
Procedure reference for a procedure call please. It
Michael Fowler wrote:
Or maybe we need a more generic solution (as someone else suggested, I
forget who). Something that allows the arbitrary execution of code, much
like @{[ ]}, but cleaner. Unfortunately, I can't think of anything
suitable.
Whatever direction this discussion takes, I
The only decision, then, is to decide which context to use; if it deparses
to concatenation then it seems logical to use scalar context. This also
makes sense in that you can force list context with @{[ $weather-temp ]} if
you really wanted it.
$ perl -le 'sub w{wantarray?"WA":"WS"};print
Greg Williams wrote:
easy to see which one will be used. By providing a single location where
/ALL/ overloaded packages would go (VIRTUALZONE::${PACKAGE}), you limit
yourself in the amount a class (or class collection) may be extended.
VIRTUALZONE:: was an example; the virtual root could
Graham Barr wrote:
I would suggest that anyone want to contribute to this discussion should
first read the thread about the addition of this pragma to perl5 in
the perl5-porters archives
