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:Object::Tiny accessors are read-only (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 restriction in OO-related literature before.
If the user of a class starts accessing the hash elements directly, then why shouldn't he also use hash access to read them?
Reply to This
Parent
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: (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?
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