What's That Noise?! [Ian Kallen's Weblog]

Main | Next day (Apr 20, 2004) »

20040419 Monday April 19, 2004

Nail Biter The Giant's had to keep you on the edge of your seat, ya know. After the string of one run loses, it just wasn't exciting enough to give the Pads the beat down.

With San Diego coming in with a 9th inning rally, bowling over the Giant's bullpen you just have to stare in disbelief as the three run lead that the Giant's enjoyed at the onset of the 9th evaporated into one. After coming off the high of Grissom and Bonds launching back-to-back home runs (and Bonds acquiring the number of man, 666), it's just inconceivable to have that victory snatched away. The rain pouring down was making it seem all the more grim.

But no need for dispair! It wasn't so bad. At the end of the night, it's another one run game but this time the G's were on the good side of it and the four game losing streak is snapped. Sighs of relief were audible far and wide.

  Runs Hits Errors
San Francisco Giants 4 7 2
San Diego Padres 3 8 1
( Apr 19 2004, 11:28:06 PM PDT ) Permalink


Perl6 and Apocalypse 12 Those wild and crazy guys behind Perl6 are at again. Larry Wall published "Apocalypse 12" the other day and it discusses many of the deficiencies of Perl5's object support.

There are a lot of funky things about Perl5. Paradoxically, sometimes these are beautiful things as well. But oftentimes, they're just funky. As I've said before "I suspect with Perl 6, I'll only hate it on Tuesdays". I could rag about the weak encapsulation and the lack of useful method signature support in Perl5. But since I've really come to love Java's use of interfaces to compose an object's capabilities and disallowed multiple inheritance, I was interested in reading about Perl6's roles. Yes, in Perl6 a class can have a bunch of different roles. Here's a little bit of Larry from Apocalypse 12:

Roles can encompass both interface and implementation of object relationships. A role without implementation degenerates to an interface. A role without interface degenerates to privately instantiated generics. But the typical role will provide both interface and at least a default implementation.
A little later, in discussing how roles are kinda like second class classes but not really, we see some hypothetical code:

If you want to parameterize the initial value of a role attribute, be sure to put a colon if you don't want the parameter to be considered part of the long name:


    role Pet[IDholder $id: $tag] {
        has IDholder $.collar .= new($tag);
    }
    class Dog does Pet[Collar, DogLicense("fido")] {...}
    class Pigeon does Pet[LegBand, RacerId()] {...}
    my $dog = new Dog;
    my $pigeon = new Pigeon;

In which case the long names of the roles in question are Pet[Collar] and Pet[LegBand]. In which case all of these are true:


    $dog.does(Dog)
    $dog.does(Pet)
    $dog.does(Pet[Collar])

but this is false:


    $dog.does(Pet[LegBand])
The universe is a big place. And it keeps getting bigger. I guess I'll wait for Damian Conway to chime in. If Larry Wall writes the bible; Damian has to write the talmud.
Shalom, Salaam, Shalom, Salaam ( Apr 19 2004, 11:06:01 PM PDT ) Permalink