Rob Kinyon wrote: >OOP is all about black-box abstraction. To that end, three items have been >identified as being mostly necessary to achieve that: > 1) Polymorphism - aka Liskov substitutability > 2) Inheritance - aka specialization > 3) Encapsulation > >P5 excels at #1, does #2 ok, and fails completely at #3. Now, one can argue >whether the programmer should make the decision as to whether strong >encapsulation is desirable, but the point is that you cannot create >encapsulation in Perl that someone else cannot violate. > >Hence, you cannot write OO code in Perl. > > >
[...] >OO is a spectrum, not a point. What I was trying to say was that when >comparing the OO you can do in P5 with the OO you will be able to do in P6, it >seems silly (to me) to cripple P6 out of a misguided effort to maintain >backwards compatibility with P5. > > [sarcasm] Indeed. In fact, in any language where coders can discover the implementation of your code they might depend upon or circumvent your wishes. Ergo, no open source code can be considered OO. In fact, if p6 isn't going to compile programs down to a binary representation-indeed, if it doesn't encrypt the resulting binary-there's no reason for anyone to ever use "object" and "perl6" in the same sentence. Woe are we. [/sarcasm] Dude, this isn't slashdot. Taking some recondite position and then defending it against all comers doesn't earn karma, or get you clickthroughs, or earn you mod points. If you think that trying to be backward compatible will have negative impacts in the long run, say that. As it is, I've just spend an hour reading "Can't do it" "Can too!" "Can not!" "Can too!" "Well, it might awkward, is all I'm sayin'" There's $150 you owe me. That's 180 bottles of Yuengling. As for the encapsulation thing, here's my take on it: I'm not a "perl programmer". I'm a coder. I write stuff in whatever language makes sense: PHP, sh, perl, C, Batch. That means that I don't keep track of the status of all the CPAN modules, not do I particularly care about the personal lives and traumas affecting their authors. BUT, CPAN makes Perl rock IMO because it can really increase my productivity (and I'm a consultant, so I always need to be more productive than everyone else). So if there's a problem I can easily state, I go look on CPAN to see if someone has already solved it. Sadly, it's only very rarely that the module is really "drop-in". The rest of the time it goes like this: 1. Given this module, can I drop it in and have it work? 2. No. Okay, can I change some of my code to interface to it? 3. No. Can I write a hook that will get the behavior I want? 4. No. If I subclass/extend it, can I trivially get what I want? 5. No. Is there another module I should consider? 6. No. Is the code itself readable and comprehensible so I can extend it? 7. No. I guess I write it myself. (Any yes answer returns, or at least yields.) Encapsulation isn't something you have to strive for. Encapsulation is something you have to work really hard to avoid. Because the only time I'm looking at (gasp!) violating encapsulation is when I have determined that your module is the best of the bunch (or at least closest to what I want) and IT DOESN'T WORK. So I'm opening the hood to answer questions 4 (unless your docs are good) or 6. That means that apparently the stars are in alignment, because I'm agreeing with Chromatic (for the second time, I think). Backward compatibility means a bunch of modules that will work, and that can be extended. I don't have to insert question 3a: "Is this written in P6 so I can do stuff with it?" I'm sure a lot of the "obvious" modules will be rewritten in P6 really soon. DBI, for instance. A lot of the "bottom feeders," are only really useful when you're in a rare circumstance. They're REALLY useful, though, when you're in that circumstance. Statistically, some authors are dead. Some have seen the sacred light and switched over to programming Ruby (or the LOTW). Some are zoned out in a crack house in some dark metropolis. But if the compatibility is good I can still use their code. Saved! (By someone who really wanted to code a Maori calendar module...) =Austin
