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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • And now the primary interface to Moose is using D:D or something like it ...

    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 debugging. Of course when MX::Declare no longer has these issues and is more mature, I will no doubt start using it more, but I can assure you that the primary Moose interface is still plain old Perl and will remain to be for the forseeable future.

    For the record, I agree with you, ... although I am conflicted. On one hand I can see all the horrors that you see, I saw them (or the potential of them) in Perl 6. On the other hand, I have to agree with chromatic, the language itself cannot be a test bed for experimentation, that type of thing belongs in modules and extensions (we use the same philosophy with Moose and new feature proposals, they have to be a MooseX:: first). Devel::Declare just expands the range within which these experiments can explore. As with all of CPAN, the crap will float to the bottom and the good stuff will rise to the top and perhaps in some cases drive forward the language itself.

    - Stevan

    • I have to agree with chromatic, the language itself cannot be a test bed for experimentation....

      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

    • 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