On 10/12/05, chromatic <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-10-12 at 21:50 +0200, Yuval Kogman wrote:
> > This has even more implications with closed classes to which you
> > don't have source level access, and if this can happen it will
> > happen - i'm pretty sure that some commercial database vendors would
> > release closed source DBDs, for example.
> Closed classes should not exist.
> At least, they should only exist if the person *running* Perl 6 wants
> them to exist -- never if merely the class writer wants to close them.

I'm not sure y'all are talking apples and apples. Yuval is talking
about lack of source-level access and the class being closed. I'm not
quite sure how we end up with a lack of source-level access,
particularly as that locks me, the user of your module, into one
specific P6 interpreter (presumably Parrot). Given the work that
Autrijus and company have been doing with PIL and Pugs in general,
closing the source (presumably by releasing Parrot bytecode) isn't
going to really work. (Plus, I can't imagine that a reverser for
Parrot code is going to be that hard to write.)

Furthermore, is releasing just the Parrot bytecode going to work in
multi-lingual apps? Aren't there optimizations that may not be
appropriate before all the languages are known? (I'm completely out on
a limb, here.)

That said, I agree with chromatic closing (or finalizing) a class
should be the action of the consumer, not the producer. Maybe the
producer could signal his/her desire to close the class when some
phase is finished. That would mean the consumer could either modify
the class before that phase is finished and/or the consumer could
intercept the request for finalization.

Alternately, maybe you have a pragma that says "Finalize all classes
unless I specify that it should remain open." Maybe, we need a
negation for close? keep_open?


Reply via email to