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)

    • 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 was pretty much the primary author of Moose, I did what I liked and what was good for me and my needs, which is stack traces. The whole reason Moose::Error::{Croak, Confess, Default} exist is because the other Moose contributors wanted a more pluggable system and so they wrote one, but the default remains confess because, well it's what I prefer (backwards compat and all that too).

        Now, to say that stack traces are "very inconvenient for application programmers" is making a blanket statement about "application programmers" that is just flat out not true and is really just your (and scrotties) opinion (and surely a few others agree with you too, but certainly not *all* app programmers). I will agree that the stack traces sometimes expose too much of the Moose internals, and at some point I would like to add support for Carp::Clan or something so that we can filter that, but right now it is an issue of tuits (I don't have any and neither do the other core contributors, want a commit bit??)

        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 their needs. Also, there are more of them.

        Well there is one big flaw in that plan, which is that the more experienced Moose developers are also the ones with more code already out in production, which may or may not need to be changed because of this. These people have been loyal users and submitted bug reports, patches, etc. I wouldn't want to screw them over just to make it easier for a casual user to just "try Moose out".

        - Stevan

        • "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