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 13 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, en
      • 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

                    • 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 my class has to change his code from

                        $foo->{a} = 'bar';
                      into

                        $foo->[4] = 'bar';
                      If I had an write accessor "a" the user of my class can always write

                        $foo->a('bar')';
                      independently from whether I implemented/overloaded it as

                      package Foo;
                      sub a {
                        my $self = shift;
                        my $arg  = shift;
                        $self->{a} = $arg;
                      }
                      or

                      package Foo;
                      sub a {
                        my $self = shift;
                        my $arg  = shift;
                        $self->[4] = $arg;
                      }
                      That's what accessors are about. Most of the time they are hashes in the Perl world, of course. That's why it is nice to have modules that provide this, Class::MethodMaker, Class::Accessors. Once I have accessors, it's easy to subclass them or overwrite or whatever to change the behaviour of "a".

                      I can even add a validation to the class, and I can do this transparently so that even then the user of my class does not need to think about the API.

                      So now you may explain your OO.

                    • 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

                    • Could you please name a particular book or article where I can learn more about your often cited coupling of writing to members with forced validation provided by a general base mechanism? I'm really willing to learn about that.

                      In the meantime, I stick with Class::Accessor [cpan.org].

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.