On Fri, 4 Oct 2002, Michael Lazzaro wrote: > Observation: We're doing a *lot* of talking past each other. > > Proposed Remedy: We need to better document our discussions so that we > don't keep having them. > > --- > > I volunteer (*shudder*) to be another grunt secretary and start > compiling a preliminary document, written as a tutorial for newbies > (because we are *all* newbies when it comes to perl6 OO) that covers > perl6 OO philosophies as they evolve -- if everyone is ok with that > idea, and if nobody else is already doing it.
Yeah! > Derived from the RFCs and subsequent discussions, here is a proposed OO > Bill of Rights: fundamental truths that I *think* are already agreed > upon, and from which all other OO laws must be derived: > > (OO Article 1) It should be possible, in general, to do anything you > did in perl5 in perl6. > (OO Article 2) perl6 should not be geared towards any one OO > methodology. > (OO Article 3) There should no longer be any hint of the implementation > of perl objects as hashes. > (OO Article 4) perl6 objects must be able to be used *universally* as > fully-fledged built-in types: scalars, arrays, hashes, etc. > (OO Article 5) perl6 OO -- at least, some definable subset of it -- > needs to be runtime-friendly. > (OO Articles 6) Also considered drop-deads: interfaces, assertions (of > various sorts), multiple inheritance, complex delegation. > > Can we at least agree on these? Are there other basic tenets that > should be included? Bravo! I suspect everything mentioned in article 6 except multiple inheritance could be delegated (no pun intended) to the zealots mentioned in article 2. > If we can reach some consensus, the next step is to start presenting > the ~10 (by my rough count) "fundamental" open issues that are screwing > everything else up. I think it would help immensely if we knew some details of the implementation of "is" properties. >From the plethora of things they are expected to do, it seems like every variable access or subroutine/method call or maybe even block invocation will need to be able to be intercepted by property classes (or whatever they are). This would certainly make perl5 'tie's easy to abolish. But there may be sticky issues about who gets called first when something has multiple properties. A think a lot of the syntax discussions could be narrowed down better if we had some inkling of the implementations. (Since properties are completely new in perl6, which apocalypse do they belong to anyway?) ~ John Williams
