Busy Weeks

chromatic on 2003-12-21T06:43:47

Two weeks ago, I left for a week at the head office in California. (They like me to drop by every now and then to prove that I'm still alive and haven't replaced myself with a complicated Perl program.) Since Sebastopol is somewhat duller at night than Portland, I always have the opportunity to get lots of work done in the evenings.

That was fortunate, since I have lots of projects on my plate. Here's a brief list of things I've accomplished in the past couple of weeks:

• Released Class::Roles. Of course, Luke Palmer rightly said "Hey, what about my Class::Role?" I'm working on ideas to unify them.
• Added a very bare-bones Template Toolkit-compatible templating system to Jellybean. This allowed me to pull the Wiki templates out of the Wiki container. As well, the templates are forward-compatible with TT2, so you can start with the home-grown templater (and it's amazingly simple) and move on to something more complex if you need it.
• Finished pulling Mail::Action out of Mail::SimpleList and Mail::TempAddress, using Class::Roles to solve a design problem that had been bothering me. (In brief, the problem is how to share code between two modules that don't necessarily deserve a common ancestor.) Perl 6 roles are going to be even more useful.
• Added a Recent Changes feature to Jellybean, though I need to revise the formatter slightly to account for new templating features.
• Populated http://sdl.perl.org/ with the barest of content above what Robrt had by default. Oh yeah, Tels and I are overseeing a new release. There's code in Subversion now, though I'm not sure how stable it is; I've been breaking diffs between beta releases into individual patches and applying the ones that makes sense. It's satisfying in the same way as untangling a knotty string, but it's also rather overwhelming at times.
• Released a new Test::MockObject, as Chris Winters noticed it was missing from the CPAN. Since I'd marked several modules for recycling onto Backpan the other day, this was my mistake.

That doesn't take into account all of the business for work, including reading and replying to feedback on Myths Open Source Developers Tell Ourselves, writing scripts for the book I'm editing, writing larger programs to process the book I'm editing, and generally attempting to stay ahead of e-mail. Nor does that cover assorted patches and feature requests for things like Text::WikiFormat. Oh, and there's a holiday or two coming up for which people expect some sort of giftage.

Roles/Traits

Ovid on 2003-12-29T15:53:10

As I understood the traits paper, traits are an improvement over mixins in part because they enforce compile-time resolution of ambiguities (going off memory here, maybe it's not compile time?). In other words, if you use two traits that supply a thing() method, you must explicitly state which method you want.

Additionally, not only do traits provide methods, they require methods. For instance, the "Lifeguard" trait may not have a swim() method, but instead assume that a swim() method will be provided for once the traits are flattened into the class definition.

Those are two features that mixins don't provide, but from what I can tell, Class::Roles does not provide this either. Is there something that I am missing, or are Perl6 roles sufficiently different from traits that these are features that will not be required?

Re:Roles/Traits

chromatic on 2003-12-29T16:27:58

(Some things are really difficult to do in Perl 5, so I punted for now.)

I believe Perl 6 will have both of those features, but there are no drafts yet of Apocalypse 12, so it's all conjecture at this point. If roles do contribute to type definitions (as they should), there probably ought to be some sort of methody requiring at some point.

One idea I like is to add an as method to call a method of a particular role on an object. That is, if Clarence does Dog, Cow, then Clarence.as( 'Dog' ).make_noise() should produce a barking sound. Mooing is left as an exercise for the reader.

Re:Roles/Traits

Ovid on 2003-12-29T23:19:37

If Class::Roles has no convenient way of ensuring that the methods to use are really present, what benefit do we get that importing or using mixins wouldn't get us? Are there benefits, or is this a "placeholder" module until roles are fleshed out?

Regarding "as": I think I like it, but I'm not sure. On one hand, it allows you to disambiguate the Dog and Cow noises. On the other hand, it seems to violate the "flattening" idea of traits since anything that uses that code now needs to know about an external heirarchy. Of course, I only read about half of the traits paper, so I'm kind of making this up as I go :)