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.
  • You are certainly entitled to your opinion and I wont try to convince you to use Moose as I am sure your opinion is not knee-jerk, however I would like to just address a few points.

    To start with, Moose is still a work in progress and is in no way up to the level of sophistication as say a full blown language, so there will be some dark and ugly corners sometimes. Some of the things we are currently working on are both startup speed (we can't reduce the "bloat", but we can at least make it less noticable) and error handling (if you don't like stack traces then you don't have to use them, see Moose::Error::Croak for details).

    As for the leakiness of the abstractions, it is rare to find any abstraction that is 100% leak free. Stop and consider for a moment that Moose (and the underlying MOP) is an abstraction of a system for writing abstractions with, it would be really hard to keep it 100% leak free.

    Lastly, I think your comparison to Switch.pm is way off. Switch.pm sucked because it was a source filter and therefore sensitive to the code used in and around it. Perl being the highly flexible language that it is, it was quite easy to write code within the switch blocks that did bad things when the macro was expanded. Moose is not and has never been a source filter, it does not have that issue. Sure it helps to sometimes know how things are working under the covers, but I must disagree with you that it is as fragile as Switch.pm is.

    - Stevan

    • Why isn't something like Moose::Error::Croak the default behaviour?

      Sure, it's convenient for Moose developers to see the stack trace. But it's very inconvenient for application programmers using Moose to be exposed to internal details, useless for debugging the mistake they just made.

      The most interesting difference between these two groups of people is that the Moose developers already know more about Moose, and how to turn the stack trace on. Moose users don't, so a sensible default would be to cater to th

      • Why isn't something like Moose::Error::Croak the default behaviour?

        Well, *I* like stack traces, both when I am developing Moose and developing with Moose. In fact, before I even wrote Moose I wrote Class::Throwable which not only gives stack traces, but allows nested exception re-throwing so you can have multiple levels of stack traces (yes, that means a stack trace showing from where you re-threw the exception in addition to the stack trace of the original exception). Since until about 6 months ago I

        • "I will agree that the stack traces sometimes expose too much of the Moose internals"

          That was actually what I meant, I'm not averse to stack traces in general.

          But the few times I've seen them, I found that the internals part of the trace tended to drown out the information useful to find out why my "has" declaration was wrong.

          • I am hoping that careful usage of Carp::Clan will help this, the real issue is striking that balance between not enough information and too much information. It has been on my TODO list for a long time now, but as i said it is all about the tuits right now.

            - Stevan

    • Hi Steven,

      Thanks for taking time to read and comment on this. I'm often the voice of dissent (I hate POE, the various ORMs, Parrot, and lots of other stuff, too). So I'm always a bit surprised when I'm not dismissed as a crank =)

      Switch might be a source filter, but it's small and has no deps. As to whether Moose is as fragile as it, I can't honestly say. That was a bit knee jerk of me to say that. But to the extent that the analogy does hold (which might not be far), I'd like people to consider not rel

      • Again, most modules aren't used because they're the coolest thing ever, but instead because they're a dep of something else.

        When you write insightful things like this, I can never take you as a crank. Like you say, only when abstractions leak is this a problem.