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