On Thu, Dec 11, 2003 at 11:29:14AM -0800 drieux wrote:
>
> On Dec 11, 2003, at 10:28 AM, Tassilo von Parseval wrote:
> [..]
> > And since my attempts to get the specs for these META.yml failed,
> >I am the more happy that the latest EU::MakeMaker creates it for me.
> [..]
>
> Excuse me while I giggle UNCONTROLably ( yes, I know
> that is read as 'screaming, in some ascii art - it was
> so intended. { ok, so I not spelt gooder in ascii either } )
>
> p0: given that 'ya' traditionally denotes 'yet another',
> it worries me that most folks do not see 'yada'
> as 'yet another dumb acronym'. Mean while we have shifted
> from 'yaml' to 'yml' as the TLA suffix...
Dropping the 'a' is mostly a concession to archaic operating systems
that tend to expect 8.3 filenames.
> p1: given that I have been living with the dialectical
> tension of the voices in my head, where on one side
> i have 'sgt. rock' asking "do we have a dog in this fight?"
> and the 'college boy' in me willing to get 'wrapped
> around the axil' for some purely pedantic "issue"....
>
> I think I'll just follow your lead Sarge....
>
> If and when they decide that we really need to
> know how exactly they want to deal with this
> "yaml-ization" I am more than sure that the
> word will come on down from on high, and at
> that time College Boy we will tell you your position...
>
> Which of course is what makes me just bend over
> and giggle at the "growth" and/or "bloat" in
>
> h2xs, the EU::MM and ...
>
> not to mention the ongoing efforts to either
> adopt the Build v. Maker Model, and the ... and ...
Especially the latter discussion has something to do with the
growth-problem. Traditionally, h2xs started as a tiny script that
created a skeletal directory structure with a few templated files in it.
However, that was obviously not powerful enough so it was tweaked to
automatically generate XS files based on some C headers fed to it.
Once XS was tackled, the question was raised why it shouldn't also
generate accessors for functions defined in C headers. This unfortately
introduced a new prerequesite, namely C::Scan which is a module that
should have never been allowed into the wild and onto the CPAN. Since
this module is a non-core module, not every h2xs has the same
capabilities. Three flavours exist: those not having any C::Scan at
their disposal, those with an old C::Scan and those with a recent enough
C::Scan so that the -m and -a options can be used (calling those
switches obscure would be too favourable).
Since h2xs should continue running on any platform, edge cases like VMS
etc. had to be handled as well.
The result over the years is a script of around 1700 lines to which
maybe 20 different people have contributed. It's living proof that
security through obscurity is in fact a decent approach when done
'properly' and with enough imagination.
Rewriting it from scratch is impossible since the code wont reveal what
it does (my attempt of doing it is still buried deep down in my
home-directory). Furthermore, those people responsible for a particular
change either died or hide in shame so that there is no person alive who
could definitely say whether a particular clean-up to parts of the code
would be functionally equivalent.
EU::MM has a very similar biography, only that it is still maintained by
one brave guy who nonetheless freely admits that M::Build should be used
instead just because at some not too distant point in the past patching
EU::MM will become impossible.
> p2: Next time I think we should have a nice clean
> useful and appropriate BDUF about how Perl Really
> should have been built, developed, maintained, so
> that all due regards to the efficiencies of the
> algorithms with conform to the matrix of maintainablity...
There is no such thing as a dictum of maintainability in the context of
Perl5. Efficiency has always been one but - when done properly - doesn't
leave any room for maintainability. But it does change the way Perl5
develops now. New features are hard to get in because the people
involved have become cautious: They know that any new piece on top could
make the whole card-house collapse. Maybe not now, but possibly half a
year later.
This is why Perl6 is on its way and promises to solve a lot of those
problems. Sometimes something functional has to be torn down in order to
build something better.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
