use Perl

• Thank you, thank you, thank you (Score:1)

  by xsawyerx (8978)

  I have to say, I really enjoy Yuval's posts, as they are.. incredibly informative. Seriously, anything the guy has to say is pure gold.

  However, much of it I have a hard time following. I would definitely fit the non-math crowd.

  Thanks for taking the time to translate Yuval's stuff, and give some insight into this. It was fun to read, really interesting and surely made an impact on the way I'll code regarding this.

  So, thanks :)
• Now I know what's been bothering me... (Score:1)

  by jjn1056 (1241)

  Whenever I see gratuitous use of "has attr => (is=>'rw',...) in some Moose classes. People often just fall to rw when they hit a problem not easily solvable, and instead of questioning fundamental design choices, they just loosen up the API.

  --
  Waiting on the Road to Eventually, I lost my Place On Line
• This is unforgivable! (Score:1)

  by nothingmuch (5848)

  I think the problem is that a significant part of the process of understanding a difficult concept involves finding the right names for the right concepts. Once you know them it's tempting to take them for granted, because this is a powerful tool for describing what you mean.

  I think your three compact rules really hit the nail on the head. While my third post addresses what you can do when the hierarchy gets complicated, it has nothing on how to get strated developing good habits.

  Anyways, thanks for posting
  • Re: (Score:1)

    by zby (4817)

    OK - so I have a Moose question here. Let's say I have a function to compute an attribute - and I want to call it at the creation time - how can I do that (coercions would not work here - because the type of the parameters is the same as the real value of the attribute and I do want to set that value sometimes).

    To be more concrete, and to tie that with the original subject: in FormHandler we have attributes called 'params' and 'input', input is computed from 'params'. I think we could get rid of 'params
    • Re: (Score:1)

      by nothingmuch (5848)

      You can make 'params' be a private attribute with a public init arg, and input a lazy readonly attributed whose builder method uses the private params.
      • Re: (Score:1)

        by zby (4817)

        Thanks - I'll keep that in mind. It does not buy too much though - still two pieces of state to keep (even though one private).
• Readonly "evil" (Score:1)

  by Sue D. Nymme (8651)

  Oh come now. Readonly may be sub-optimal for some cases, but does it really rise to the level of "evil"?

  Readonly works at run-time. That's a feature. While there are many places where it would be better if it worked at compile-time, it (currently) doesn't have that capability.

  The compiler cannot take advantage of Readonly variables' immutability, as you point out -- but does that really make all use of the Readonly module evil? Tone down the rhetoric a notch, please.
  • Re: (Score:1)

    by Alias (5735)

    When used for package-level scalars Readonly has only one real advantage. It interpolates.

    In exchange for interpolation, your code is larger, slower and adds a non-core dependency.

    It's exactly this sort of module that we've seem time and time again, it adds a small convenience for a disproportional expense. People are lured into making their code worse for shiny beads.

    Overuse of version.pm, inside-out objects, bundled non-optional coverage tests, the list goes on and on. People are encouraged to use somethi