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.
It should encompass, at minimum:
(1) Definitions of common terms, so that everyone in these discussions
understands what-we-mean-by-the-word-"blah", -for us-, as opposed to
"in language X" or "according to the concepts of Y". We shouldn't have
to hedge about what words like "private" or "interface" mean, we should
discuss it, define it, and have it explicitly written down.
(2) An appendix that lists any open and closed issues, "closed" meaning
we reach a consensus recommendation that Larry/Damian could easily look
at without wading through the fission reactions that led to them. So
that issues can actually be "closed", for starters, and so that when
Larry/Damian gets to the related Apos & Exes, they have at least
something better to start from.
(3) A small gallery of proposed cookbook problems & solutions,
demonstrating suggested syntax as it's agreed upon. This will allow
everyone to verify that common problems can indeed be solved, in at
least one canonical way, using the concepts proposed. As the OO
Apocalypse(s) are finalized, the solutions get changed to match.
In creating that "tutorial", we can have something that an outsider can
read and get up to speed quickly, and hopefully we will have something
that we can easily tweak into being "real" documentation after the
appropriate Apocalypses are completed.
OK, having said that, and providing nobody wants to shoot this idea
down:
---
A refresher glance through the RFCs indicates that, at least at that
time, there was precious little agreement on OO details, other than it
should remain basically perl, but Better, for some widely divergent
definitions of Better. Since then, we've gotten a much clearer idea of
what Larry was aiming for, and I think we can agree that the RFCs do
not adequately document the evolving thoughts on perl6 OO.
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. It may no longer be the best way, or the
preferred way, but it should be possible. This includes runtime
manipulation of both inheritance and method dispatching, for example.
(OO Article 2) perl6 should not be geared towards any one OO
methodology. perl6 should be a powerful sandbox by which individuals
-- both amateur and professional -- could create and distribute new
object methodologies; OO zealotry shall be delegated to the modules
produced by those later individuals. "Out-of-box" perl6 OO should be
geared towards providing all the necessary hooks by which zealots may
easily manufacture their wares.
(OO Article 3) There should no longer be any hint of the implementation
of perl objects as hashes. $obj->{ myAttr } is dead. Objects _might_
internally be implemented as hashes, or as anything else, but no part
of the syntax should imply hash structure. perl6 objects will be first
class ... well... objects.
(OO Article 4) perl6 objects must be able to be used *universally* as
fully-fledged built-in types: scalars, arrays, hashes, etc. Operator
overloading and tie() will never again longer conflict, because if the
OO stuff is truly correct, tie() as we know it won't need to exist.
Operator overloading, including those pseudo-operators required for
"tied" access, will be folded into OO methodology.
(OO Article 5) perl6 OO -- at least, some definable subset of it --
needs to be runtime-friendly. Runtime overhead must be kept tolerable.
It certainly can't be, for example, an order of magnitude slower than
similar non-OO code. It should be possible to program web
applications, high traffic data-warehousing code, etc. in OO without
paying speed penalties so outrageous as to disqualify OO from being
used.
(OO Articles 6) Also considered drop-deads: interfaces, assertions (of
various sorts), multiple inheritance, complex delegation. Don't have
to use them, but they should be there if you want them.
Can we at least agree on these? Are there other basic tenets that
should be included?
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.
MikeL
