> =head1 CHANGES
> 
> Comments received have been that it would be better to use AUTOSCALAR,
> AUTOHASH etc instead of AUTOGLOB in the interests of encapsulation.
> The argument being that if you only want to implement AUTO scalars in
> your program, then doing:
> 
> C<if($type_of_thing eq 'scalar') {
>         # do some stuff
> } else {
>         SUPER::...
>         # use our parent's AUTOGLOB
> }>
> 
> breaks encapsulation.  However, these sort of shenanigans are common in
> other OO languages such as Java and C++, and in any case, we still need
> to 'break encapsulation' like this if RFC 8 is implemented.  If
> programmers really want to use AUTOHASH, AUTOSCALAR etc then they can
> put their own suitably constructed AUTOGLOB subroutine in the UNIVERSAL
> class which will do all the appropriate magic.

I think you missed my point a little. :-) I wasn't just saying that
AUTO* are prettier to look at, but for polymorphic method delegation
they're a necessity. Any method that internally reinvokes others must
explicitly decide on a method to reinvoke to - this is the part that
breaks encapsulation. Having one sub means you can't delegate to
multiple packages.

Check out these RFC's:

   RFC 193: Objects: Core support for method delegation
   RFC 190: Objects: NEXT pseudoclass for method redispatch
   
In multiple inheritance this gets really entangled - having Perl
dispatch to the correct type is actually a considerable simplification
and benefit. Otherwise you can't delegate globbing of specific data
types to other classes, which is something you'd conceivably want to do.

Also, all I was trying to say about "controlling what's globbable" is
that we're going to have to do this somehow. :-) Perl will have to do
one or the other of these:

  AUTOGLOB
  ========
    1. Found a %hash that's unavailable
    2. Pass to AUTOGLOB('HASH', \%hash)

  AUTOHASH
  ========
    1. Found a %hash that's unavailable
    2. Pass to AUTOHASH(\%hash)

Anyways, I'm not going to keep harping on these points. You've mentioned
them in the RFC; if you change your mind after reading the above RFC's
that's cool, otherwise leaving the RFC as-is is fine with me. But note
that my suggestions also change your proposed migration section from:
 
  =head1 MIGRATION FROM PERL 5

  Changes from the semantics of AUTOLOAD mean that existing AUTOLOADs
  will almost certainly break badly if simply renamed.  Therefore it
  would be wise to keep the existing AUTOLOAD (although deprecated)...

To

  =head1 MIGRATION

  None. New functionality.


Cheers,
Nate

Reply via email to