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 26 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • 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, ensure the object is legal, and then keep it that way.

      So in this case, no Object::Tiny won't be getting read-write accessors. It's feature bloat :)

      • 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

        • f the user of a class starts accessing the hash elements directly, then why shouldn't he also use hash access to read them?

          So I don't make $object->tyops(). Though a tied hash would also take care of that...oh, well (without the parens, it also saves some typing)

          • Ha! I waited for this answer. :-)

            So why would one protect against typos in read access but accept their chance when writing to the members?

            And why don't you also want save some typing in writing?

            • > And why don't you also want save some typing in writing?

              Because, at least for the things I write, writing generally Has Implications.

              By having the object ALWAYS be valid and correct while in existance, it means both that anyone taking an object never has to check it, it is always correct.

              But it also means that anything where they are writing to an attribute requires param-checking, validation, potentially deeper implication (flushing caches when you move a source directory) and so on.

              Reading is a simpl
      • 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

        • I’m not sure I follow. Did I miss the fact that O::T hides the hash from you or locks it? Or does the fact that it only provides read-accessors but not mutators somehow prevent you from writing mutators? Or something? How are O::T objects immutable?

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

            • That’s just smoke and mirrors. Someone has to create those mutators, and that someone needs to know about the underlying implementation.

              It does not buy you much either. Even if you are using a method maker module to pretend not to know anything, your objects are not subclassable without knowledge of their guts any more than they would be with any other approach: subclasses must use the same method maker module to add their own accessors, so they need to need to know how the superclass is implemente

              • Hm, you are basically arguing that I can subclass to add write accessors. For that, of course I need knowledge about internal representation.

                But if O::T already had read/write accessors, all your subclassing would not have to fiddle with internal representation of members.

                And if one argues, that I can add write accessors by myself, why not create an Object::Really::Tiny that simply does nothing but is even more faster and more lightweight? Think of all the freedom you get from the possibility to cr

                • I’m not sure what point your sarcasm is supposed to make. It misses the point entirely.

                  O::T is just supposed to save a bit of typing. Now how often do you need straight mutators that just assign to a variable with no validation whatsoever? If often, then something is wrong with your OO designs. If very rarely, as it should be, there’s not much point to including that functionality in O::T, since, well, it’s rarely needed.

                  So if you wanted to include mutator generation, it would require

                  • I’m not sure what point your sarcasm is supposed to make. It misses the point entirely.

                    No. I don't miss the point. And especially not "entirely". I hate it when you say that. :-)

                    Object::Tiny is by its own doc about "Class building".

                    "Class building" is OO. Accessors are OO. This is a good moment to repeat my question:

                    Please show me literature about OO where "accessors" are introduced as a read-only concept. They are used to decouple the access to the members from their implementation (hash, array, whatever).

                    Now how often do you need straight mutators that just assign to a variable with no validation whatsoever?

                    Validation checks have nothing to do with the final step of assi

                    • So what? The only code that should need changing when you change the internal representation is the code inside the class, anyway. So for use inside the class, non-validating mutators protect against a change that is rare and involves only code that you have control over. What’s the point?

                      And exposing non-validating mutators to API clients is bad. I’m not sure whether you are confusing literature about Java with literature about OO, but OO is not about structs with loosely associated procedure

                    • In the entire time I have been writing Perl, I can remember changing the internal object structure (from a HASH to a SCALAR ref from memory, for speed reasons) exactly twice.

                      I have no problem rewriting a bunch of code in that case.

                    • So what? The only code that should need changing when you change the internal representation is the code inside the class, anyway.

                      This is plain wrong, at least for write access to members, which is what we are talking about. But let's start at the beginning.

                      Even if I had read too many Java books, the "accessor" thing is quite common. To make it more understandable I will try to explain what I understand as (one aspect of) OO. In my OO world I can change the internal representation e.g. from hashes into an ordered array. My member "a" becomes, for instance, the 5th element of a blessed array. Without write accessors the user of m

                    • Never ever did I say the user should write $foo->{a} = 'bar';. That’s wrong. But $foo->a('bar')'; is just as wrong in terms of OO design. It increases encapsulation a tiny bit, but it does not decrease coupling. Mutators that do not validate the value they are passed are almost never necessary in a good OO design.

                      And if you do need such a mutator, then knowing that $self is a hash ref and using it to implement the mutator is not a problem, since that knowledge remains isolated to the class its

          • Nope, it doesn't lock anything.

            It's just that the DEFAULT implementation does not allow for ->method('foo'), Object::Tiny only implements ->method.

      • 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');

        If you would be so kind to add write accessors to Object::Tiny you could improve even your own code once you come to those last 10%, e.g. Module::CGI::Install line 130:

        $self->{cgi_path} = ...

        Once it had write accessors I for myself would switch to that module in favour of Class::Accessors which I currently had a closer look to in order to substitute an overblown Class::MethodMaker based module because that really pollutes my namespace.

        • I find your use of "Improve" interesting, mostly because it implies both that it would be better, and additionally that there is a need to make it better.

          For simple module that won't accumulate a large diversity of subclasses, I have no problem whatsoever writing to the hash element directly from within the same class that defines the property itself (You'll note I work directly with it in the new constructor as well).

          Also, that value can also be passed in directly.

          Module::CGI::Install->new( cgi_path =

          • I find your use of "Improve" interesting, [...]

            Please pardon my way of becoming personal. I originally wanted to show code that uses O::T to make it obvious what I mean and your module was the only one I found. I did not originally intend to let it sound as personal as it does, the way I phrased it in the end.

            To become more concrete, what I mean, is the following patch. Full patch with tests is at http://renormalist.net/misc/object_tiny_write_accessors.patch [renormalist.net].

            diff -ur Object-Tiny-1.03/lib/Object/Tiny.pm Object-Tiny-1.04/lib/Object/Tiny.pm
            --- Obj

            • I have two problems with that sort of change.

              1. It makes EVERY accessor writable, which is a BAD idea. I generally require that all objects are valid at all times, so allowing anything to arbitrarily change accessors is really really nasty.

              2. It makes the accessors slower (I think) because of the extra conditional.

              The change I was looking for was more for keeping the default read-only, but to add additional read/write accessors.
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.