Re: RFC 137 (v1) Overview: Perl OO should I<not> be fundamentally changed.

>>>>> "PRL" == Perl6 RFC Librarian <[email protected]> writes:

  PRL> A C<private> keyword that lexically scopes hash keys to the current
  PRL> package, and allows hashes to contain two or more identically named (but
  PRL> differently scoped) entries. This would solve the problem of
  PRL> encapsulation in OO Perl for the vast majority of (predominantly
  PRL> hash-based) class structures.

does that apply to a set of keys? or a particular hash ref used as the
object? 

  PRL> =item *

  PRL> A new special subroutine name -- C<INIT> -- to separate construction
  PRL> from initialization. C<INIT> methods would be automatically -- and
  PRL> hierarchically -- called whenever an object is created.

INIT currently has a useful meaning in perl5. it is like BEGIN but it is
called after the compilation phase is done and before runtime starts. i
have found uses for it where i put an INIT block which sets up some data
structures (could be complex file i/o) in front of the code that uses
it. if that was a BEGIN block, the setup would execute even if there was
a compile time error later in the file.

so pick another name. CREATE (spelled correctly!), SETUP are some
ideas..

would a parent INIT get called even if there is no INIT in this class?
how would you travel up the @ISA tree and call INIT?

  PRL> Changes to the semantics of C<bless> so that, after associating an
  PRL> object with a class, the class's C<INIT> methods are automatically
  PRL> called on the object. An additional trailing C<@> parameter for
  PRL> C<bless>, to allow arguments to be passed to C<INIT> methods.

i like that. 

  PRL> Pre- and post-condition specifiers, which associate code blocks with
  PRL> particular subroutine/method names. These blocks would be automatically
  PRL> called before and after the subroutine/method of the same name, and
  PRL> trigger an exception on failure. For methods, pre- and post-conditions
  PRL> would be 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? maybe the post
condition one is useful as you can return from multiple places. does it
have access to the return values? same for the pre-, does it see @_?
also how would they affect 'want'?

  PRL> =item *

  PRL> Class invariant specifiers, which associate code blocks with a particular
  PRL> package/class. These blocks would be called automatically after the the
  PRL> execution of subroutine/method of the same name, and trigger an
  PRL> exception on failure. For methods, invariants would be inherited and
  PRL> called hierarchically.

how is this different from the post-condition above? 

  PRL> A C<NEXT> pseudo-class, enabling resumption of the dispatch search
  PRL> from within an invoked method, as well as the "rejection" of invocation
  PRL> (e.g. by an C<AUTOLOAD>).

great. this solves several problems. 

  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.

  PRL> =item *

  PRL> A new pragma -- C<delegation> -- that would modify the dispatch
  PRL> mechanism to automatically delegate specific method calls to specified
  PRL> attributes of an object.

no more need for AUTOLOAD of accessors? what about complex ones (like i
showed you the other day off list)?

  PRL> That in Perl 6, only hashes (and perhaps pseudohashes) may be blessed.

you just blew chapters 4 & 5 of your book out of the water! :)

  PRL> This would result in no loss of functionality, since any other data type
  PRL> that was previously blessed as an object could instead be made a
  PRL> single attribute of a blessed hash. However, combined with the proposed
  PRL> C<private> keyword and C<use delegation> pragma, this proposal would
  PRL> ensure that it was always possible to inherit from an existing class
  PRL> without detailed knowledge of its implementation.

why not make that a pragma?

use object 'hash' ;

  PRL> =head1 MIGRATION ISSUES

  PRL> Virtually none. That's the point. :-)

good point.

i like it overall.

perl could be the uber OO language, capable of emulating ANY object
style.

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