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
about I/O disciplines and I should retire to the Tassili-in-Aijer
mountains in Sahara as a camel herder :-)
-- Jarkko Hietaniemi
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Object::Tiny accessors are read-only (Score:1)
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++
Re: (Score:1)
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
Re: (Score:1)
> 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
Re: (Score:1)
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)Re:Object::Tiny accessors are read-only (Score:1)
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?
Reply to This
Parent
Re: (Score:1)
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