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
several minutes ago. We don't need no stinkin' tactical nukes.
(By the way, do you have change for 10 million people?) --lwall
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
alternative metadata systems (Score:1)
This is the thing about sub attributes: they turn into a mess as soon as you try to do anything complicated with them. Java has tried to solve this with annotations. Those don't look so hot to me, but they do work better for this amount of metadata. Mason has a special markup for adding attributes to components. It's somewhat easier to read than this, but still not actual perl code.
The simple approach is to have some kind of explicit configuration instead, like CGI::Application does. Then your metad
Re:alternative metadata systems (Score:2)
The problem with "configuration" is that you often have significant effects being generated by something which is not visible in the code. As a result, yes, attributes look appealing. Unfortunately, I don't see this being easily solved in a "clean" manner in Perl 5 :(
Reply to This
Parent
Re: (Score:1)
The "configuration" that perrin was talking about in CGI::Application modules *is* visible in the code because it's just in a
setup()method. It's not magical, it's all localized (no need to guess where the dispatch rules are scattered throughout the application) and it's just plain code.I'm not saying that it's perfect or can't be improved, but sometimes we try to be too magical just to save some minor style nits. But I have to admit that I'm really excited that Perl 6 is going to do it better by making su