Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

unimatrix (1124)

unimatrix
  (email not shown publicly)
http://www.codewerk.com

Journal of unimatrix (1124)

Wednesday October 03, 2001
04:29 AM

Aspect-Oriented Programming in Perl

[ #857 ]

Aspect-oriented Programming comes to Perl.

I've uploaded an alpha distribution to CPAN, and it's also available from http://codewerk.unixbeard.net/aspects/Aspect-0.04.tar.gz. There is a "perl-aspects" mailing list at http://www.astray.com/mailman/listinfo/perl-aspects.

What is Aspect-oriented Programming?

Aspect-oriented Programming (AOP) is a programming methodology developed by Xerox PARC. The basic idea is that in complex class systems there are certain aspects or behaviors that cannot normally be expressed in a coherent, concise and precise way. One example of such aspects are design patterns, which combine various kinds of classes to produce a common type of behavior.

Another such aspect concerns debugging or tracing the flow of execution. Maybe every time one of a set of subroutines is entered or exited, you want to want to print a line telling you so. Normally you would you the good old 'print' statement debugger, or maybe you would actually use a custom Perl debugger or a C module. But what if the profile produces too much output you're not actually interested in? And a custom debugger usually does not make for reusable, easily customizable code.

You might change the source of all those subroutines you're interested in to print the desired information. When you are done debugging, you remove the print statements again. That's a lot of effort and can lead to bugs and oversights of its own. Furthermore, your code is littered with unsightly print statements. If you want to change the output, you have to change every print statement. If you add a class, remember to add the print statements. It's a mess. Wouldn't it be easier if you could influence the behavior of those subroutines from the outside, like a switch you could flip to make them print a statement when they're entered (in a consistent way, without chance of forgetting to create or remove a print statement), then flip the switch again to turn that behavior off?

That's what aspect-oriented programming is about. Aspects usually concern many classes right across the class hierarchy. One says that they "crosscut the program structure" and refers to them as "crosscutting concerns".

Just like object-oriented programming (OOP) encapsulates the concepts and functionality of individual classes and arranges them in a class hierarchy, so does AOP encapsulate the concerns of many classes and make those aspects or behvaviors reusable. In this way AOP is orthogonal to OOP.

Aspects allow you to change the interaction of objects without breaking their encapsulation. You don't change the behaviors of the objects per se, but rather the way they behave at the seams, at well-defined points during execution. For example, you can intercept method calls, override methods, influence operators, and generally influence the flow of execution in a way that isn't possible without AOP.

Certainly you can achieve all these things without AOP, but it would be a lot harder, less (or, more likely, not at all) reusable and more error-prone. Just as you can simulate any object-oriented program using non-OO techniques, but OO makes things just so much easier.

By modularizing such concerns into aspects you ensure consistent behavior across your project and don't depend on individual programmers to follow a convention, say, on how to write security or error checking. Indeed, it may not be necessary to for individual programmers to write code for such concerns at all, if they're centrally managed, from the outside, as it is, by aspects.

Tuesday July 03, 2001
07:07 AM

Exporter::Simple

[ #368 ]

Here is another module using attributes to simplify an API and hide implementation details. This time it's Exporter's API. Exporter::Simple, when used by a package, allows that package to define exports in a more concise way than using `Exporter'. Instead of having to worry what goes in `@EXPORT', `@EXPORT_OK' and `%EXPORT_TAGS', you can use two attributes to define exporter behavior:

    my @bar : Exportable(vars) = (2, 3, 5, 7);
    my $foo : Exported(vars) = 42;
    my %baz : Exported = (a => 65, b => 66);

    sub hello : Exported(greet,uk) { "hello there" }
    sub askme : Exportable { "what you will" }
    sub hi : Exportable(greet,us) { "hi there" }

You get the idea. I wasn't sure whether to emulate attributes for globals as well, but seeing that they're going to be in Perl 5.8.0, I'm going to wait until that's out before revising Exporter::Simple for a clean solution.

Enjoy. Feedback, as always, is welcome.

Friday June 29, 2001
09:41 AM

Perl 6 proof-of-concept page

[ #351 ]

I've done a web page with information and links to Perl 5 modules that may be of interest to those discussing and implementing the Perl 6 language. Some of them are proof-of-concepts of Perl 6 features that the respective authors have implemented to show how things might work in Perl 6.

It's at http://www.codewerk.com/perl6/.

Additions and suggestion for the page are welcome, please send them to marcel@codewerk.com.

Wednesday June 27, 2001
05:40 PM

Scalar::Properties

[ #341 ]

After reading a journal entry here, James Duncan sent me some pretty cool code showing how to get constant overloading and literals-as-objects working as intended. At that point, Scalar::Properties had become an inevitability. Let me amuse you with an excerpt of the module's synopsis:

            use Scalar::Properties;
            my $val = 0->true;
                if ($val && $val == 0) {
                print "yup, its true alright...\n";
            }

            my @text = (
                'hello world'->greeting(1),
                'forget it',
                'hi there'->greeting(1),
            );
            print grep { $_->is_greeting } @text;

            my $l = 'hello world'->length;

Tuesday June 19, 2001
01:01 PM

Graphing Makefiles

[ #316 ]

While playing with Makefiles, I had the urge to know what depends on what, hence GraphViz::Makefile was born. Coming to a CPAN near you rsn (i.e., after the most pressing other stuff gets done).

12:51 PM

YAPC::NA afterglow

[ #315 ]

Revision: Without Damian, it would only have been half a conference, but without Kevin, Luc and Rich, there would have been no conference. Congratulations on organizing it and keeping it running smoothly.

On the flight back I was thinking about Ruby's literals-as-objects and realized that Perl can do this as well. By overloading constants, you can do things like

        print 42->times(3);
        print 'hello world'->reverse;

This could be used for runtime properties:

        return 0->true;

Now we need to override the test for definedness to also check for this property along with the value.

12:01 PM

YAPC::NA::END{}

[ #312 ]

YAPC::NA 2001 has finished. The time went by too fast, but it was fun. Lots of ideas and inspirations. And I've met many people whom so far I've only known from IRC or mail or newsgroups.

After the auction (where I actually bought a Ruby book and learned about its literal objects; nice) a bunch of us went for dinner in a lovely French restaurant. We split up into several groups as we didn't want to run the by-now-familiar risk of being turned away due to large numbers, and Abigail, Leon, Isabel (of NY.pm) and freeside had dinner, and we did something else afterwards, but I just can't seem to remember what. Drinking, probably. Someone mentioned to Abigail that he thought Klingon sounded like angry Dutch.

Saturday lunch we had the CPAN BOF, where we had to book a hotel room as there were about 30 people. Brian, who apparently hadn't slept all night, tried to convey his napc-idea (think CPAN + Napster for binary builds... watch this space) and there were other intense discussions. CPAN is great, and other languages would kill to have something like it, but there's still lots to do.

Then dha, Skud, Leon, Brian and many more went down into the old town to have a few drinks. A card game called "Chez Geek", the blame protocol and a long-expected rain (with impressive impromptu rivers down the sloped streets of Montreal) come to mind, in no particular order.

Sunday I just walked around lots; dinner at Mr Yan's again; now it's Monday and I'm writing this in a cafe just before going to the airport. Will be able to upload it only in Vienna, though.

NB: At the airport now. Complete rip-off: on top of an expensive flight, you have to pay CAD 10 when going through customs. "Oh, we just thought we'd rip you off some more before upholding our end of the deal."

Friday June 15, 2001
12:06 PM

YAPC::NA. Day 3. Lunch.

[ #303 ]

We had some problems with wireless this morning, so this entry is a bit late. We don't do steenkin' wires.

Yesterday afternoon saw Damian's amazing "Life, The Universe and Everything" talk - where he mixes Conway's (no relation) Life, Klingon, Perl 6, Maxwell's Demonsa and more in a talk that you just had to be there - Damian at his best.

This morning mjd gave his talk on the dirty innards of the regex engine and the identity function. Next was Leon's talk about creating compilers for little languages using Parse::RecDescent or Parse::Yapp and abstract syntax trees; a concept with huge potential. Very exciting stuff.

And finally I had my debut as a Perl conference speaker: A lightning talk on Aspect-Oriented Perl. I was a bit nervous just beforehand, but up on stage, it quickly passed. Even Abigail liked the idea. Bodes well for my first full-fledged talk on "Handling Attributes" at YAPC::Europe.

Speaking of stages, for the last lightning talk, Damian and Brian took the stage to present Inline::Files in a Shakespeare-style play, in which, amongst other things, Damian (or rather, his character) called Brian('s character) the "puppet of an active state". It was an incredible talk and there were standing ovations at the end.

A Perl conference without Damian is no Perl conference.

Now I'm looking forward to the Perl 6 status meeting after lunch. Speaking of which...

Thursday June 14, 2001
08:24 AM

YAPC::NA. Day 2. Morning.

[ #291 ]

Fixed two bugs in Inline with Brian Ingerson. Discovered that Data::Denter is very slow with big data structures with circular references. Worked some more on Getopt::Attribute, which is being uploaded as we speak.

I survived Abigail's Parse::RecDescent talk.

Lots of talk, some more ideas, smoked meat bof (bof good, beef bad - but hey, at least they don't have foot & mouth here, so you gotta get all the meat you can). Then a few of us went to a french restaurant / bistro. Pretty nice.

Currently I'm in gnat's Perl Internals class. Tonight will still see Brian's 'Data Denter & YAML' talk, Abigail's 'Return of the JAPHi' and Damian's 'Life, The Universe and Everything'. As well as the YAPC dinner.

More on that later.

Wednesday June 13, 2001
06:42 AM

YAPC::NA Day 1. Morning.

[ #285 ]

Setting up registration in the afternoon was pretty painless . Went to a restaurant a few blocks away from the conference in the evening. Which turned out to be somewhat of an uncoordinated effort as poor Mr Yan couldn't cope with 40 hungry hackers, so about half had to be turned away as he "didn't want to give them bad service". Which is a nice attitude.

Met up with acme, Brian Ingerson, dha, Gurusamy Sarathy and had some more crazy ideas which this time I'm *not* going to add to my long list of projects as the list is already, well, long.

Now it's early morning (though the jetlag still caused me to wake up at 5.30am, so no change there) and they're just setting up breakfast and registration behind us as acme, gnat and me are updating our journals.

Some minor and not so minor glitches: Michel Rodriguez can't make it, so something else has to be arranged presto - for a 1.5 hours talk that's supposed to start at 10am. Fun!

gnat brought a wireless network base station - but no power cable. Thankfully there's an abundance of hubs to compensate. Nothing wireless, though.

Ah, lenzo has just turned up. Which means we'll have airport again soon.

Later.