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 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.
Re: RFC 193 (v1) Objects : Core support for method delegation
"PRL" == Perl6 RFC Librarian [EMAIL PROTECTED] writes:
PRL One powerful application of delegation is as a replacement for
PRL inheritance where the internals of a prospective base class are
PRL inaccessible or inconvenient, or the base class was not designed
PRL to be inherited and yet it must be.
isn't this a HAS_A type of relationship? i have plenty of these in my
new project and it is a pain. i can't inherit as the objects are really
not related but one uses the other, e.g. i have a high level obejct with
a socket and a buufered_io object. i don't want to inherit from buffered
i/o since its methods may collide with the main object. but some methods
i want to be able to be passed to buffered i/o and have nothing to do
with the main object.
PRL sub new {
PRL my ($class, $infile, $outfile) = @_;
PRL bless {
PRL in = IO::File-new($infile) || die,
PRL out = IO::File-new(" $outfile") || die,
PRL }, $class;
PRL }
PRL use Class::Delegation
shouldn't that be use delegation? i think you have a cut and paste
error.
PRL in = [qw( getline getlines getc ungetc eof read sysread
PRLinput_record_separator input_line_number )],
what about a way of delegating ALL the methods of an object? any way to
signify that?
in = 'ALL',
will look up all current methods (maybe tagged?) from the class 'in' and
handle that. then you don't have to update all the delegation calls each
time the 'in' object changes.
i like this RFC a lot. but i like most of damian's stuff. or at least
what i understand. :-)
uri
--
Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net -- http://www.northernlight.com
Re: RFC 193 (v1) Objects : Core support for method delegation
PRL One powerful application of delegation is as a replacement for PRL inheritance where the internals of a prospective base class are PRL inaccessible or inconvenient, or the base class was not designed PRL to be inherited and yet it must be. isn't this a HAS_A type of relationship? Yep. i have plenty of these in my new project and it is a pain. Yep. Hence this RFC. PRL use Class::Delegation shouldn't that be use delegation? i think you have a cut and paste error. You're correct. Many thanks. (That's what I get for pre-testing all the code in my RFCs! ;-) PRL in = [qw( getline getlines getc ungetc eof read sysread PRLinput_record_separator input_line_number )], what about a way of delegating ALL the methods of an object? any way to signify that? in = 'ALL', will look up all current methods (maybe tagged?) from the class 'in' and handle that. then you don't have to update all the delegation calls each time the 'in' object changes. Specifying Cin = [] does that. See the description of "catch-alls" below the bit you've quoted. Damian
Re: RFC 193 (v1) Objects : Core support for method delegation
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?
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.
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.
PS You mentioned Class::Classless. Does any other language or system
implement deligations?
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
Long, long time ago, in a far away galaxy, cells were formed. Cells are
building blocks of different chemicals.
--Alex Chiu, Immortality Guy
Re: RFC 193 (v1) Objects : Core support for method delegation
"DC" == Damian Conway [EMAIL PROTECTED] writes: PRL use Class::Delegation shouldn't that be use delegation? i think you have a cut and paste error. DC You're correct. Many thanks. DC (That's what I get for pre-testing all the code in my RFCs! ;-) heh, you should hire me to proofread your rfc's. just like the book. :-) will look up all current methods (maybe tagged?) from the class 'in' and handle that. then you don't have to update all the delegation calls each time the 'in' object changes. DC Specifying Cin = [] does that. See the description of "catch-alls" DC below the bit you've quoted. ok, it was not clear to me that is how they are to be used. i would expect catchall to be the main mode of use as you generally want to just pass thtough to a HAS_A object all of its methods. only if you collide with another HAS_A object (or with the parent object) would you have to worry. and then you might just control the order or manually deal with the method in question. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
