I'm in the middle of trying to nail down the semantics of the object systems I want to support in Parrot. What I thought was going to be simple is turning out... not to be.
I'm not a big object fan, and never really have been. I joke about it at times (my initial exposure to objects was less than wonderful), but the religious fervor and "OO is the way to go!" mantras that people seem to have really grate. There's far too much knee-jerk reaction going on. Mine included, of course.
That, oddly enough, isn't actually a problem--it's a help, but it's not enough of a help.
The bigger problem is the definition of what an object and an object system really is. Somewhere on the web there's a list of the characteristics of an OO system, but the joke is that it's a "pick 4" list. And it's true. It's easy to round up a half dozen languages that are all unarguably (or mostly unarguably) do OO style programming, but they all do things differently. While that's not considered a huge problem for most people--it's not often that you'll be inheriting from a C++ class in Smalltalk--it's a problem for me. (And I'd argue that mutually incompatible object systems is a big problem, but that's a rant for another time)
Parrot, you see, is supposed to unify this sort of stuff, at least well enough to allow minimal functionality. Sure, it's not really Larry's primary goal for Perl 6, but Parrot's long-ago moved past that, at least as the driving design goal. And even if we were sticking with just Perl, a Perl 6 style class inheriting from a perl 5 style class (or vice versa. Or worse, from each in turn several times, with MI) is an interesting and potentially non-trivial thing if you want to do more than just give a passing nod at the problem with a "Don't do that" warning. And I hate those warnings.
In addition to both styles of perl objects, we have to throw Python and Ruby into the mix, though luckily they don't expand stuff much. (Python objects are reasonably primitive as objects go, though they're a bit closer to traditional objects than perl 5 does. Ruby's a full-blown OO system, but as a pretty direct descendant of Smalltalk it fits in well with most other OO systems) Plus, of course, C++, .NET, and Java objects, at least in some form or other. I'd also like Objective-C in the mix, as I'm an OS X guy now, but as that's a C/Smalltalk mix it doesn't pose any semantic issues.
I think, though, that I've finally done it, at least well enough to get by. It's taken a while to distill down the necessary semantics, and it's been at least as much work to figure out which semantics we aren't implementing (sorry classless OO languages--you're still on your own), but I've got it boiled down, I think. More to the point, I think I have a good front-end API so that even if things don't work on the back end (inheritance across styles of objects) they will work on the front end, in user programs.
The first goal, as always, has been to be able to transparently use an object of any type from within parrot. That's nailed, for our problem domain, though it's taken a while to realize. The second goal, to transparently use classes, is nailed enough to write the spec. And so, off to write the spec I go.
Posted by Dan at March 9, 2003 11:51 AM | TrackBack (0)