Re: RFC 193 (v1) Objects : Core support for method delegation
Michael G Schwern [EMAIL PROTECTED] writes:
On Mon, Sep 04, 2000 at 09:53:39PM -, Perl6 RFC Librarian wrote:
Objects : Core support for method delegation
I like it! One gripe (of course)...
The proposed delegation mechanism would work via a pragma:
use delegation
attr1 = [qw( method1 method2 method3 )],
attr2 = [qw( method4 method5 )],
attr3 = [],
attr4 = [],
I will often use a more complicated data structure for my objects,
often organizing all sub-objects into a hash of hashes...
$obj-{locks}{MacOSX} = $macosx_obj;
$obj-{locks}{Mac}= $mac_obj;
$obj-{locks}{BSD}= $bsd_obj;
which is nice when you stuff alot of things into an object. If I
wanted to deligate to those objects in $obj-{locks}, how would I
under your proposal?
Flatten the hierarchy? Make your aggregations into classes themselves
and set up delegation rules there?
In a similar vein, I can see a use for wanting to deligate a set of
methods to an entire list of objects. Consider...
$obj-{locks} = [$macosx_obj, $mac_obj, $bsd_obj];
it would be nice to be able to state that "method1" should deligate to
each object in the $obj-{locks} list until it is found.
package ListOfObjects;
use strict;
use Symbol qw/gensym/;
sub new {
my($class) = shift;
my $self = bless {}, ref($class) || $class;
$self-push(@_);
}
sub push {
my $self = shift;
while (shift) {
my $attr = gensym;
$self-{$attr} = $_;
use delegate $attr = [];
}
}
Also, what happens when a deligated attribute does not contain an
object when Perl checks? Should it produce a warning? I'd say no. I
can easily see cases where you'd like to be able to deligate to
objects which may or may not be instanciated at run-time. If a
warning was issued, it would be difficult to circumvent. You'd have
to place a dummy object in that slot.
You know, this may be a case for Mister Fowler's RFC about auto
instantiated objects. Except CDog $self-{attr} isn't actually valid
syntax is it? There's certainly a case for just using the (singleton)
null object as a placeholder until a real object comes along, and it
can solve a host of other problems.
--
Piers
Re: RFC 193 (v1) Objects : Core support for method delegation
Damian Conway wrote: attr3 = [ALL] It was (and is) a good suggestion. I suspect however that it should be attr3 = [__ALL__] Any consideration given to the :all export-like tag? attr3 = [:all]# could be uppercase too -Nate
Re: RFC 193 (v1) Objects : Core support for method delegation
When you want to turn off an inherited delegation in an ISA situation? Um, I don't think I understand the question. I'm confused by the question, too. Delegation is not inherited. Any module you inherit from you won't use for delegation, AFAIK. They're two different beasts. But from outside the class, you can't tell whether a method was inherited or delegated. Derived classes inherit whatever behaviour the base class provides (method dispatch to ancestors or method delegation to attributes). If your base class delegates calls to Cdelmeth, you can prevent that delegation by defining a Cdelmeth method in the derived class. Is that what you meant? Damian
Re: RFC 188 (v1) Objects : Private keys and methods
exists (sometimes causes autovivification, which affects Ckeys)
That's not technically accurate--exists never causes autovivification.
print keys %hash, "\n";
exists $hash{key}{subkey};
print keys %hash, "\n";
Or did that get fixed when I wasn't looking?
No, the - operator has not been changed to do lazy evaluation.
(And yes, of course I know the distinction that makes you techically
correct, but I don't think it is germane to this argument :-)
I just don't like reading "exists causes autovivification" when it doesn't.
If it did, then
exists $hash{key}
would trigger this--but it doesn't. It's the act of dereferencing
indiscriminate of L/R-value context that does this. And given that
subroutines' args are lvaluable, it will take a serious hack to
change this. Even the tricks needed to make
fn( $a[3] )
not autovivify was long in coming.
--tom
Random camel droppings on this matter follow for those who would
contemplate an RFC about it.
On References:
This is one of those cases mentioned earlier in which references spring
into existence (or "autovivify") when used as an lvalue (that is, when
a value is being assigned to it). Supposing C$array[3] to have been
undefined, it's automatically defined as a hash reference so that we
can set a value for C $array[3]-{"English"} in it. Once that's
done, C $array[3]-{"English"} is automatically defined as an
array reference so that we can assign something to the first element in
that. Note that rvalues are a little different: Cprint
$array[3]-{"English"}-[0] only defines C$array[3] and C
$array[3]-{"English"} , not C $array[3]-{"English"}-[0] ,
since the final element is not an lvalue. (The fact that it defines
the first two at all in an rvalue context could be considered a bug.
We may fix that someday.)
On Operators:
Just as in C and C++, the binary C - operator is an infix
dereference operator. If the right side is a C[...] array
subscript, a C{...} hash subscript, or a C(...) subroutine
argument list, the left side must be a reference (either hard
or symbolic) to an array, a hash, or a subroutine, respectively.
In an lvalue (assignable) context, if the left side is not a
reference, it must be a location capable of holding a hard
reference, in which case such a reference will be Iautovivified
for you. For more on this (and some warnings about accidental
autovivification) see LChapter ##, References.
On Functions under exists():
REXPR can be arbitrarily complicated, provided that the final
operation is a hash key or array index lookup:
if (exists $hash{A}{B}{$key}) { ... }
Although the last element will not spring into existence just
because its existence was tested, intervening ones will. Thus
C $$hash{"A"} and C $hash{"A"}-{"B"} will both spring
into existence. This is not a function of Cexists, Iper
se; it happens anywhere the arrow operator is used (explicitly
or implicitly):
undef $ref;
if (exists $ref-{"Some key"}) { }
print $ref; # prints HASH(0x80d3d5c)
Even though the C"Some key" element didn't spring into
existence, the previously undefined C$ref variable did suddenly
come to hold an anonymous hash. This is a surprising instance
of Iautovivification in what does not at first--or even
second--glance appear to be an lvalue context. This behavior
is likely to be fixed in a future release. As a workaround,
you can nest your calls:
if ($refand
exists $ref-[$x] and
exists $ref-[$x][$y] and
exists $ref-[$x][$y]{$key} and
exists $ref-[$x][$y]{$key}[2] ) { ... }
Re: RFC 193 (v1) Objects : Core support for method delegation
Perl6 RFC Librarian [EMAIL PROTECTED] writes: This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Objects : Core support for method delegation I *want* this. Delegation is cool. Delegation that gets set up at compile time and is marked as such and can thus be optimized is *really* cool. -- Piers
Re: RFC 193 (v1) Objects : Core support for method delegation
On Mon, Sep 04, 2000 at 09:53:39PM -, Perl6 RFC Librarian wrote: The proposed delegation mechanism would work via a pragma: use delegation attr1 = [qw( method1 method2 method3 )], attr2 = [qw( method4 method5 )], attr3 = [], attr4 = [], # etc. ; This would cause method calls whose names match an element in the first list to be delegated to the "attr1" attribute of an object. Likewise, calls to a method whose name appears in the second list would be forwarded to the "attr2" attribute of the object. That is, calls like: $obj-method3(@args); $obj-method5(@other_args); Is this not just a module which creates the necessary subs in the calling package ? The catchall can be done with an AUTOLOAD sub. Graham.
