On 8/18/00 11:56 AM, Larry Wall wrote:
> I'm not sure we have to throw out the orthogonality of OO to data
> structure to get what you want.
Do you mean orthogonality of syntax or implementation? Or both?
It seems like it might be both cleaner and easier to allow "Perl 5 o-o" to
live on largely unchanged, in all it's orthogonal glory, as a means of both
ensuring (untranslated) backwards-compatibility and freeing Perl 6's o-o
from baggage. In particular, I think the whole notion of old-style
datatype-based objects should not be part of Perl 6's "native" o-o
implementation.
Clever blessed filehandle tricks and such aside, collection-based objects
are by far the most common in Perl 5: hashes dominate, with array-based
classes often appearing only because of efficiency issues. Perl 6's native
o-o could allow object poking via something that *looks* like data structure
access, but every object should have the same (efficient) implementation
underneath. Hand-waving example:
class Person
{
set the "I look like a hash if poked in a naughty manner" flag;
my attributes are: name, age, blood_type;
...blah blah blah...
}
...
Leading to this situation:
$fred = Person->new;
...
print $fred->name; # Very fast!
print $fred->{'name'}; # Naughty, "emulated" behavior: slower!
If someone wants an "old style" hash-based object, they should use Perl
5's o-o, which, again, would stick around in Perl 6.
> we need to either settle on a standard syntax/implementation or make sure that
> variant syntaxes/implementations will interoperate, particularly under
> derivation.
Granted, the mingling of "Perl 5 o-o" and a Perl 6 "native" implementation
that's "made more decisions for you" is kind of ugly. If the best of both
worlds can be combined, that's great. If not, I'd rather err on the side of
a fancy "native" Perl 6 o-o implementation than end up with a super-tweaked
version of Perl 5's o-o.
I dunno where everyone else comes down on this, but I have a feeling that
the Perl o-o-heads are of a similar mind set, and the procedural folks don't
care one way or the other. Is there a vast middle-ground that wants the
orthogonality of blessed data structures to remain *the* system for Perl 6
o-o?
It's hard to make everyone happy. Perl 5 more or less kept all the Perl 4
folks happy, bending over backwards not to ruin their day as it ventured out
into the foreign land of o-o. Okay, so there was that \@ issue, but mostly
it played it safe :) As a bonus, the clever way that Perl 5 implemented its
non-disruptive o-o turned out to offer a ton of flexibility and many
opportunities to do interesting things.
As we start on Perl 6, a lot of the Perl 5 object experimentation has given
way to many workmanlike o-o Perl applications and modules that stick to
essentially "standard" o-o behaviors. Of course, everyone's got their own
little pet module or set or rules for "standard" behavior, so your objects
are likely to behave differently than my objects, even though both are
likely "hash based." Interoperability is sometimes a pain, and you never
really know what to expect from each mysterious blessed thingie you run
across (Now is it $fred->set(-age => 10) or $fred->set(Age => 10) or
$fred->age(10) or do I have to do $fred->{'age'} = 10 or even $fred->[AGE] =
10?)
And efficiency drags the whole lot down, stamping Perl with the "good for
prototyping" label. Glass half full: "It's easy to write powerful
applications quickly in Perl!" Glass half empty: "Perl is too slow for
production o-o applications."
There's no reason (heh, easy for me to say) that Perl 6 can't be just
as dynamic a language as Perl 5, but with a radically more efficient
and nicely standardized o-o implementation. Perl 5 introduced o-o in
a necessarily cautions manner. I think we're all on board for a much
bigger o-o change in Perl 6. At the very least, let's make mistakes
at the other end of the spectrum this time :)
("Make new mistakes." Who said that? Hmmm...)
-John
