Please send corrections and additions to firstname.lastname@example.org.
The lists have been very light recently. During the last two weeks of June, three of the mailing lists received a mere 142 messages across 20 different threads. 40 different authors contributed. Only 5 threads generated much traffic. Eventually, I'll come up with a better way of reporting these meaningless metrics.
Now, at the end of the day, I have no fewer than five JVMs installed, all completely different implementations of two Java standards. As a Perl programmer, I find this abhorrent. Installing any version of Perl release in the last 7 years is no different from installing any other release: download, extract, ./configure -des, make, make test, make install. Done.
Elaine Ashton, however, disagreed, to a point:
I don't believe I was saying that. My point was that you had a bad experience installing Java on FreeBSD and have declared that it sucks to install it. Unsurprisingly, I have never had a problem installing or supporting Java on Solaris but there are plenty of things to grumble about Perl sometimes, especially if you deploy multiple versions and configurations across multiple platforms and multiple versions of those platforms.
Michael Schwern pointed out that Solaris is "Sun's Blessed Platform", and it shouldn't be surprising that Java should install easily there. The discussion then touched a bit on distributions, licensing, support roles, and, yes, even George Carlin.
bless could take, and
ref return, a list, allowing for a cleaner multiple-inheritance model for
objects in Perl. Dan Sugalski
simplified the request to object-based vice class-based inheritance, and then
provided some potential trade-offs.
Damian, of course,
submitted code to fake it in Perl 5. He did muse about an
ISA property, though, which would act like
@ISA, but at the object level.
Doing it properly in a module is significantly more of a pain than doing it in the core. Faking it with a module means a fair amount of (reasonably slow) perl code, doing it in the core requires a few extra lines of C code in the method dispatch opcode function.
To which, of course, Michael Class::Objected:
I've already done it, it was easy. Adding in an object-based inheritance system should be just as easy, I just need an interface. $obj->parents(@other_objs) is a little clunky.
...Look at Class::Object! Its really, really thin. Benchmark it, its no slower than regular objects. http://www.pobox.com/~schwern/src/Class-Object-0.01.tar.gz
[The Golden Troll Award goes to Dan Brien for this gem.]
Dan Sugalski initiated discussion on the internal API for strings:
Since we're going to try and take a shot at being encoding-neutral in the core, we're going to need some form of string API so the core can actually manipulate string data. I'm thinking we'll need to be able to at least do this with string:
- Convert from and to UTF-32
- lengths in bytes, characters, and possibly glyphs
- character size (with the variable length ones reporting in negative numbers)
- get and set the locale (This might not be the spot for this)
- normalize (a noop for non-Unicode data)
- Get the encoding name
- Do a substr operation by character and glyph
David Nicol suggested implementing strings as a tree, vice a contiguous memory block. After some pondering, this seemed to grow on Dan, and he is awaiting a yea-or-nay from Larry. Copy-On-Write for Strings will also be implemented, although there was no mention of a potential key signature.
Simon Cozens released an updated version of his Perl 6 emulator.
Marcel Grunauer announced a Proof-of-Concepts page for Perl 6, which contains info and links to Perl 5 modules that may provide a glimpse of things to come.
There were more
complaints about operator choices. (Specifically,
~ for string concatenation, and
. (the dot) for dereference (vice
There's but three weeks till TPC 5.0 kicks off in San Diego.
Bryan C. Warnock