>>>>> "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
