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
--Donald E. Knuth
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Making Development Harder (Score:1)
I'd have some sympathy if there were any chance of getting (for example) function signatures, the
methodkeyword, or theclasskeyword into Perl 5 this side of the heat death of the universe, but that's not going to happen because "that would make maintaining existing code harder".Moderated -2, troll, wrong (Score:1)
Re: (Score:2)
Which demonstrates my point that there will be an increasingly widespread use of source filters... (I'm assuming that's what that it implemented using).
No source filter required (Score:2)
Nope, MooseX::Method::Signatures is Devel::Declare and a heaping spoonful of other magic.
Re: (Score:2)
... and Devel::Declare is a source filter, albeit (as peregrin put it on #p5p) "keyhole source filters".
Re: (Score:2)
While its true DD and traditional source filters both change the source code, it is unfair to simply lump DD in with source filters. "Source filter" is a dirty word. DD does not share the traditional problem with source filters, that of trying to parse Perl and their global nature. For example, a source filter might decide to alter code-like strings and regexes. DD won't be fooled by that. It gets around this problem by (ab)using Perl's own parser.
DD brings in its own bag of problems, but calling it a
Re: (Score:2)
I agree that it does not share some of the side-effects, and the level of collateral damage is greatly reduced.
But it still makes arbitrary changes to the lexical structure of the language. From a static parsing point of view, THAT is the critical problem here.
The problems with collateral damage are only a problem from the point of view of an executing parser.
Re: (Score:1)
I meant in the Perl 5 core.
Actually No (Score:1)
Actually, MooseX::Declare is just another way to use Moose, but very surely not the primary.
Many people are using MooseX::Declare, and find it very nice and elegant, but many others (myself included) are not willing to use MooseX::Declare or Devel::Declare in production because it is not yet mature enough. Personally, my reasoning is that I feel it still exposes too much internals when it errors and makes for some difficult d
Re: (Score:1)
I agree, but that's not my main point here.
It is a mistake to canonize features before they're ready, unless you have some mechanism of indicating that they may change in subsequent releases. No one wants the chaos of frequent churn.
It's also a mistake, possibly more severe, to refuse to add features widely-requested and often reimplemented in subtly incompatible ways.
Having D::D available with core support is
Re: (Score:2)
I've updated the post to remove the suggestion that the CURRENT Moose API is D:D, or that it is specific to just Moose
Circles should be square (Score:2)
I seem to recall something Nat said in his "What's With Those Python Fucks Anyway?" rant that "circles should be square so they're easier to draw and measure".
While I sympathize the the folks that write tools to do static analysis of Perl code, it seems rather putting the cart before the horse to restrict language development to serve those tools. It should be the other way around. It would be nice if we had formal Perl 6 style grammars to make life easier for the toolsmiths, but I'm not holding my breath
Re: (Score:2)
If you could create the best language in the universe, but it could only be written using Notepad (or an equivalent), would anyone actually use it?
Support for good toolchains appears to be correlative with the success of a language (although proving this, and then further proving causality, would be an interesting exerci
Re: (Score:2)
Sadly, yes. A less panicky question would be to say if you could do without syntax highlighting and indentation, which is really all the Perl specific stuff I use. I'd miss indentation, but syntax highlighting I can live without.
That said, its not EITHER we have tools OR we get to play with the language. The tools have already had to reverse engineer the entir
Weighing Options (Score:2)
Considering this:
I think it gains me nothing. Nothing at all.
Considering this:
If I can get that (amongst other things), I will cheerfully give up:
Different people value different things. I'd hate to give up the items on that list, but I'd much prefer to work with a program
Re: (Score:1)
That's why D::D should only be a prototyping tool and eventually such features should be available from the core.
Note, however, that making the new syntax available with a "feature" invocation carries virtually the same problems as D::D. You never know from static analysis (and non-recursive) whether it's on or not. But at least this would mean it's blessed and to be considered part of the language.
Re: (Score:2)
Well, the difference with use feature is that at least in that case it's official, in the core, works the same on every operating system and every host, and doesn't require the parser to leave the document.
So it's possible to add the relevant special casing in, where in the generic DD case that is not true.
Re: (Score:1)
Not really. Consider Modern::Perl, common::sense, and their ilk. And besides the ones on CPAN, any codebase can contain its own equivalent. Sure, you can special-case
strict.Re: (Score:1)
That example of MooseX::Declare like code is well intentioned but I (personally) think *horrific* for proving your point.
function morning (Str $name) {
say "Good Morning $name"
}
This won't piss off the people who think you're pushing OO at them.
Re: (Score:2)
Both can be made available, but don't forget that Perl doesn't really know the differences between functions and methods. That being said, I want a modern language and P5P is too conservative to provide that to me. Regrettably, they may be right.