>>>>> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
>> does that apply to a set of keys? or a particular hash ref used as the
>> object?
DC> It applies to the nominated keys of the nominated hash.
DC> private $hash{secret}; # Just this key is private
DC> private @hash{qw(name rank snum)}; # All these keys are private
DC> private %hash; # All the current keys are private
how does this handle a key which is a variable? or doesn't it matter? i
think this is for private use by a method to access an attribute so that
should always be via a constant key. but AUTOLOAD generated closures
must have vars for the key. do you require the AUTOLOAD check the
validity of the accessor?
DC> 1. You can inherit conditions whilst replacing implementation
whilst! never seen that one in a technical forum.
>> also how would they affect 'want'?
DC> They wouldn't. What had you conjectured?
well since they can be executed just before a method returns, it may
need to know the calling context. it can do something with the return
value based on that context and then return it to the real method caller.
DC> An invariant is called after *every* method, not just a specific method.
DC> Think of it as a generic post-condition.
clear up your description then. in fact since i was confused about some
of this, i would like to see a better description with some example code
like you have shown a little here.
PRL> A new pragma -- C<delegation> -- that would modify the
PRL> dispatch mechanism to automatically delegate specific method
PRL> calls to specified attributes of an object.
>>
>> no more need for AUTOLOAD of accessors?
DC> No, AUTOLOAD will still be useful. This is more for when you want to
DC> inherit from a class that you don't have control over, or that wasn't
DC> designed to be inherited. You can aggregate instead and then delegate
DC> method calls to the corresponding attribute. For example:
i didn't think autoload would go away, but its use would be lessened.
DC> use TheirWeirdClass;
DC> use TheirLastWeirdClass;
DC> use delegation
DC> theirotherbit => 'TheirOtherWeirdClass::',
DC> theirlastbit => 'UNKNOWN';
DC> sub new {
DC> my %self = (
DC> theirbit => TheirWeirdClass->new(),
DC> theirlastbit => TheirLastWeirdClass->new(),
DC> );
DC> bless \%self, $_[0];
DC> }
DC> $obj->theirweirdmethod1();
DC> $obj->theirweirdmethod2();
DC> to be treated as:
DC> $obj->{theirbit}->theirweirdmethod1();
DC> $obj->{theirbit}->theirweirdmethod2();
damn, i need that right now!! i have objects which are contained by but
not inherited from others and i have to explicitly create methods to
propagate calls to get access to the parent methods.
also my setup involves callbacks and so creates reference loops as the
parent object (which is called back) owns another object which has a ref
to the parent object. i need explict shutdown methods to handle breaking
the loop. without using weak refs, could something in this rfc handle
forcing a call to the child or parent shutdown/DESTROY? i do this
explicitly and it will be more of a pain as i add more contained objects
with callbacks to the parent object.
>> you just blew chapters 4 & 5 of your book out of the water! :)
DC> "No sacrifice too great..."
hmm, send me the royalties for those chapters then. :)
DC> I'm not sure I like it myself since it dramatically reduces the WTDI.
DC> It's only virtue (?) is that, like other types of gags and straight
DC> jackets, it solves a multitude of problems -- the genuinely insane, the
DC> utterly uncontrollable, the truly evil, the merely different -- by
DC> locking them all up and throwing away the key.
sounds like what they should do to you! :)
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
