Phoenix.pm: Perl 6 Apocalypse 12

[Scott Walters]

Two weeks? Already? Damn. I'm way behind schedule. I started to
read it. 

I don't like traits. They're mix-ins. Mix-ins punt on OO design. 
Rather than figuring out where in the inheritance hierachy to
place something, you just suck it in anywhere you feel like. This
makes it hard to talk about things in the general, which is the
primary point of OO. They lead to bad design or no design. It
makes for an OO equivilent of "global code", where the logic all
exists in one place because you've sucked it in. I think Java
went the right direction with single inheritance plus interfaces. 
That encourages delegation and design. 

Everything that happens in Perl 6 is the result of lobbying by
one person or another. In this case, it's chromatic, an O'Reilly
editor, and he vehomently argues that traits aren't mixins even
as Larry and the rest of the world describe them that way. 

The bit about getting to the implmenetation of the class thorugh the
.meta attribute was kind of interesting, so you can dig around in
the information used to dispatch and get under the hood. 

Other than that, what you said ;) 

I guess Ruby and C# let you do obj.foo = 10 to mean obj.foo(10) and
there was quite some fuss on the perl6-language list that this wasn't
included. Some people coughed up 20 or 30 line code snippets that went
under the hood and created setter attributes and parallel methods 
prototyped to lvalue context (ugh) that emulated it but there's quite
a gap between "possible" and "easy and obvious for novices". Things 
only go into wide use in the latter case. Of course, you can still
return lvalues as in Perl 5, but making the assigned in value look like
an argument to the method requires the mucking with the OO guts to tie
a dummy object which gets returned in that context.

Re: traits, properties, and roles, traits bolt logic onto data storage
to change how the data storage works. Properties bolt logic onto values
to change how the values present themselves. In Perl (5 and 6), you've
got something going on like...

[symbol table or pad] -> [variable name] -> [container SV/AV/HV] -> [value]

Right now, it's possible to tweak the container quite a bit. Scalar::Util
and Hash::Util do this, as do tieing. Perl 6 standardizes these things into
traits. That is, anything done to the container is logic contained in a trait.
Traits are introduced with "is". On the other hand, very little can be done 
with the value itself in Perl 5. Perl 6 makes values complex. Attributes
do this. They're introduced with "but". So every time you see one of these
words you know that an object somewhere is being dynamicly subclassed.
I try not to think about it. Roles are mixins for proper objects. It's
basically multiple inheritance, but this is really busted. Something
"is a" something else if it can serve as that thing for all intents
and purposes. Something "has" something else if it holds a reference
to that other thing (or can create one as needed). The first is very
important for OO modeling. This lets you classify which methods can
take the output of which other methods. Perl 5 has a funny thing called
"can":

  perl -e 'sub foo { }; die unless main->can("foo");'

can() checks if a method is defined. Perl 6 might have this. Well, Perl 6
does a step further with does(). does() checks for mix-ins. Mix-in 
interfaces aren't real interfaces! It is completely parallel to the OO modeling.
In Java or any other OO language, if something implements an interface or
uses a mix-in, it counts as that type. Not Perl 6. This is near the top of
my "not going to use it" list. chromatic by the way is one of my arch nemesis.

I wish I had something to add other than explanation, but for the 4 or so
pages I've read, you've nailed my feelings exactly. It's good to see an
OO system on Perl that makes instance data work correctly with inheritance
and 'use strict' and require less syntax. After all, you don't access
automatic/stack variables as $stack[$level]->{variable}, which is
exactly the sort of thing you have to do if you want to write assembly
code that's recursive safe and doesn't pre-allocate storage for each and
every variable each routine might need at any point. Yet $foo->{variable}
puts the work onto the programmer of creating storage implementation.
Yuck =P

My largest gripe right now isn't with anything they're doing in Perl 6
but rather how alienated they've made people to the process even though
it is in fact open. If nothing else, not even pretending to be interested
in what joe Perl user thinks, they're robbing themselves of lots of
free labor. People get involved in projects when they feel like it is
theirs in some small way, and when you tell people to "wait in the lobby"
so to speak, well, that's more like a commercial thing where you either
buy it or you don't and if you don't like it, too bad. Which is okey
unless you really need the free labor. And for Perl 6, they really do.
It's turned into one of those things where a few people do 90% of the
work, and the more work they do, the less interested other people are
and the more work they wind up doing. It's a downwards spiral. Mono,
(the free CLR/C# runtime/compiler) on the other hand, has done a good
job of recruiting and coordinating. As a parting stab, there are two
related gripes with the Perl 5 VM that dominate all otheres: poor
documentation, and few people understand how the really groddy innards
work. Parrot was meant to fix this situation be rewritting it. Well,
since it is all being written by a few people with virtually no 
overlap between parts, essentially only one person understands how
each part works (the JIT, runops, garbage collection, etc). And since
only a few people are doing the work they don't have time to write
documentation, so no significant documentation has been writte in
_years_. Parrot has grown the worst attributes of the Perl 5 VM. 
*stab* *stab* *stab*

Disclaimer: it is in my nature never to be happy with anything. My 
dissatisfaction is what drives me. So I hope no one is offended that I'm
nothing but critical. 

-scott

On  0, Andrew Johnson <aj at exiledplanet.org> wrote:
> 
> It's been a couple of weeks since Larry Wall releaed Perl 6 Apocalypse 
> 12, in which he explains the Perl 6 object model.  It's rather long 
> (supposedly 80 printed pages).  Given our recent discussion on Perl 6 
> syntax, I wondered if anyone in the group had any thoughts on the new 
> Apocalypse?
> 
> Since I brought up the subject, I can start the discussion:
> 
> Likes:
> *I really like the basic syntax choices.  You declare a class by using 
> 'class', and methods by using 'method'.  They're still packages and subs 
> underneath, but Perl 6 takes care of that for you. 
> 
> *There is a default constructor, so you don't have to declare new() 
> methods in every class structure you create.
> 
> *The annoyance of  '$self=shift' in every method is gone; $.attrname 
> will automatically mean the 'attrname' value of the current object.
> 
> Dislikes:
> *Secondary Sigils.  Yuck.  Class methods especially seem complicated 
> with them.  
> 
> * I think the syntax:
>     my Dog $spot .= new(...)
> looks _awful_.  Of course, one does not have to use that syntax, but 
> stuff like that is going to trip up Java/C/Perl 5 programmers, IMHO.
> 
> Confusion:
> *I'm still a bit unclear about how traits, properties, and roles work.  
> Traits sort of look a bit like Java interfaces, but not exactly.  
> Somebody apparently likes them enough to port them to Perl 5 though: 
> http://search.cpan.org/~stevan/Class-Trait-0.03/
> 
> Remember, this is all my US$0.02.  Comments?  Questions?  Explanations?
>