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.

Jonathan Rockway throws down the gauntlet on Object::Tiny 25 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Thanks for the response :)

    BTW, s/on/an/ in my name.

  • Regrettably, it still requires a blessed hashref, but that's a small price to pay for a prototyping tool.

  • Hi, regarding

    Further, Object::Tiny lets you pass your params in directly, without having to wrap them in an additional HASH reference that will just be copied ANYWAY inside the constructor.

    and

    Object::Tiny accessors are identical in speed to Class::Accessor::Fast accessors, but Object::Tiny constructors are TWICE as fast as Class::Accessor::Fast constructors, DESPITE C:A:Fast forcing you to pass by reference (which is typically done for speed reasons).

    Speed is not the only reason, and I believe its no

    --
    life is short
    • ..the error message from perl will tell me the exact
            line number where I made the mistake, and not the line inside your
            constructor where you assign @_ to an hash (the common approach).

      That's what Perl Best Practices recommends too, I think,
      although it looks terrible.

  • Unfortunately, Object::Tiny accessors are read-only.

    So there's one little thing that Class::Accessor has over Object::Tiny. (For about 30 seconds until Adam goes and adds it.)

    Otherwise, Object::Tiny++

    • Accessors ARE read-only...

      Frankly, I don't get this obsession people have with mutators.

      90% of the time, you want to make a data object of some sort with the attributes fixed at create-time.

      90% of the time, it makes little to no sense to have values changing after the object is created.

      This sort of thing is silly.

      my $object = Foo->new;
      $object->param1('foo');
      $object->param2('bar');


      It leaves the code in a transitional state that may will be illegal.

      FAR better to just provide it to the constructor, en

      • It’s not like it’s hard to write them manually. What O::T provides is just a simple hash-bashed object after all.

      • > Accessors ARE read-only...
        > Frankly, I don't get this obsession people have with mutators.
        > 90% of the time, you want to make a data object of some sort with the attributes fixed at create-time.
        > 90% of the time, it makes little to no sense to have values changing after the object is created.

        I strongly disagree.

        Accessors are invented to get control over accessing the object attributes. From where did you derive the restriction to read-only or write-only? I have never read such res

      • Accessors are not read only. For a polymorphic system that allows transparent overloading of setter methods, writing to objects must be done via accessors too.

        I would actually to so far as to that the initialization should use the accessors too (encapsulation of validation, rocket engine startup, etc.).

        Object::Tiny should be renamed Object::Immutable::Tiny

          • Well, I follow one simple rule. I don't care about the object representation (Hashref, Arrayref, InsideOut, esoteric stuff, ...) and never access instance vars accept through accessors ... and I haven't written a simple accessor myself since 1999. So an object that doens't have setters is immutable.
  • Class::Accessor has the advantage that it doesn't abuse import() to do something other than importing just to get a more compact syntax.
    • Last time I checked though, the abuse of import is hardly considered a cardinal sin on the level of, say, adding UNIVERSAL:: methods.

    • Does it matter?

      In fact, since O::T creates accessors with the given names, it’s arguable whether it’s even abuse in the first place.

      • I find it unnecessarily confusing to use import for non-importing tasks. It's usually done only as syntactic sugar, not because it actually needs to happen at that stage. It's not a huge problem, but I appreciate the fact that modules like Test::More let's me use a more traditional alternative syntax.
            • I like the idea of generating the accessors at compile time. In that regard, is is a lot like importing.

    • To be clear, the abuse in import is the @ISA manipulation.

      Otherwise, the import is passed a list of methods and Object::Tiny creates them in the caller's namespace. That they happen to be created on the fly instead of mapped to subroutines defined in Object::Tiny doesn't really matter, in my opinion.

  • You might want to move the POD document to a separate .pod file or inline them before __END__, so it doesn't increase the memory usage.

    The document is a few kilobytes but apparently that would be a bit siginificant for your ::Tiny module if you want to claim the small memory footprint :)
    • Well, scratch this silly comment :) I remember I've heard that Perl allows a run-time access to the POD document tree in some of the past YAPCs but cant find the reference to it anymore. I guess it doesn't matter as long as you use __END__. I might be wrong again :)
      • It's probably a good idea anyway, it might save reading an extra block from the filesystem :)
  • I should comment for anyone reading this on the use.perl.org front page that I tend not to proof journal entries, because I don't expect them to end up on the front page :)

    There's a cleaned up revised version in my actual journal page.
  • Can you make a similar comparison between Object::Tiny and accessors.pm? At least this module uses the same syntax as Object::Tiny, declaring accessors in the "use" line.
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.