Uri wrote:
> PRL> A C<private> keyword that lexically scopes hash keys to the
> PRL> current package, and allows hashes to contain two or more
> PRL> identically named (but differently scoped) entries. This
> PRL> would solve the problem of encapsulation in OO Perl for the
> PRL> vast majority of (predominantly hash-based) class
> PRL> structures.
>
> does that apply to a set of keys? or a particular hash ref used as the
> object?
It applies to the nominated keys of the nominated hash.
private $hash{secret}; # Just this key is private
private @hash{qw(name rank snum)}; # All these keys are private
private %hash; # All the current keys are private
> INIT currently has a useful meaning in perl5.
Arrgh. That had slipped my mind. I'll find another name. Thanks.
> would a parent INIT get called even if there is no INIT in this class?
Yes.
> how would you travel up the @ISA tree and call INIT?
Actually, you travel *down* the @ISA tree: the most ancestral INITs are
called first.
> PRL> Pre- and post-condition specifiers, which associate code
> PRL> blocks with particular subroutine/method names. These blocks
> PRL> would be automatically called before and after the
> PRL> subroutine/method of the same name, and trigger an exception
> PRL> on failure. For methods, pre- and post-conditions would be
> PRL> inherited and called hierarchically (with disjunctive
> PRL> short-circuiting, in the case of post-conditions).
>
> can't this just be done with calls from the method sub?
No, you want to separate conditions from implementation for several reasons:
1. You can inherit conditions whilst replacing implementation
2. You can impose new conditions whilst inheriting implementation
3. You can disable conditions in production code
4. One condition can be applied to several variants of a multimethod
5. You don't clutter your method implementation with testing code
> does [a postcondition] have access to the return values?
Yes, as well as the original arg list.
> same for the pre-, does it see @_?
Yes.
> also how would they affect 'want'?
They wouldn't. What had you conjectured?
> PRL> Class invariant specifiers,
>
> how is this different from the post-condition above?
An invariant is called after *every* method, not just a specific method.
Think of it as a generic post-condition.
> PRL> An optional constraint (C<use strict 'objvars'>?), making it a fatal
> PRL> error to store a object reference in a non-typed lexical.
>
> would that be defaulted in use strict; like the others are? i think it
> should be.
I agree.
> 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?
No, AUTOLOAD will still be useful. This is more for when you want to
inherit from a class that you don't have control over, or that wasn't
designed to be inherited. You can aggregate instead and then delegate
method calls to the corresponding attribute. For example:
package MyClass;
use TheirWeirdClass;
use TheirOtherWeirdClass;
use TheirLastWeirdClass;
use delegation
theirbit => ['theirweirdmethod1', 'theirweirdmethod2'],
theirotherbit => 'TheirOtherWeirdClass::',
theirlastbit => 'UNKNOWN';
sub new {
my %self = (
theirbit => TheirWeirdClass->new(),
theirotherbit => TheirOtherWeirdClass->new(),
theirlastbit => TheirLastWeirdClass->new(),
mybit1 => "mine",
mybit2 => "all",
mybit3 => "mine!",
);
bless \%self, $_[0];
}
If $obj is an object of class MyClass, then the C<use delegation> shown above
would cause the calls:
$obj->theirweirdmethod1();
$obj->theirweirdmethod2();
to be treated as:
$obj->{theirbit}->theirweirdmethod1();
$obj->{theirbit}->theirweirdmethod2();
It would also cause any method for which there is an identically named method
in class TheirOtherClass to be similarly delegated to $obj->{theirotherbit}.
And it would cause any method that can't be otherwise dispatched, to be
delegated to $obj->{theirlastbit}.
All these delegations are performed in the autoloading phase, but before
AUTOLOAD is considered. In fact, since the C<use delegation> delegates
all unknowns to $obj->{theirlastbit}, in this particular case AUTOLOAD
would never be considered.
> PRL> That in Perl 6, only hashes (and perhaps pseudohashes) may
> PRL> be blessed.
>
> you just blew chapters 4 & 5 of your book out of the water! :)
"No sacrifice too great..."
> why not make that a pragma?
>
> use object 'hash' ;
Because the idea is only useful if it's universally applied to every OO
module designer from day zero of Perl 6. The idea is that you can always
inherit from a class because it *must* have been implemented as a hash
(since that's the only thing that's blessable).
I'm not sure I like it myself since it dramatically reduces the WTDI.
It's only virtue (?) is that, like other types of gags and straight
jackets, it solves a multitude of problems -- the genuinely insane, the
utterly uncontrollable, the truly evil, the merely different -- by
locking them all up and throwing away the key.
Damian
