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? Rob
