Re: Class attribute get/set approach flaws?

The main reason I don't like this is because it makes inheritance awkward. If you are inheriting from another class that's using such an 'attrib' function as well, you have to know which attributes it's dealing with (it may for instance do validation), and you'll have to filter those and pass it to SUPER. With a long inheritance tree, this becomes awkward.

Another reason I don't like it is that, as presented, anyone can set and inspect any attribute. That includes typoed attributes, or just someone being "nasty".

And I fail to see the benefit for the user of this class. To me, the only advantage I can see is that the author of the module saves adding a few accessors - at the expensive of an inflexible, complicated, do-it-all routine.

Good modules are optimized for the user, not the author. (Even if the same person performs both roles).

Perl --((8:>*

Comment on Re: Class attribute get/set approach flaws?

Replies are listed 'Best First'.
Re^2: Class attribute get/set approach flaws? by radiantmatrix (Parson) on Nov 29, 2005 at 16:00 UTC
Another reason I don't like it is that, as presented, anyone can set and inspect any attribute. That includes typoed attributes, or just someone being "nasty". Isn't this pretty much always true? Besides, I did mention that validation was a necessary part of implementing this concept: validation could easily include "you are(?:n't) allowed to modify this value". And I fail to see the benefit for the user of this class. To me, the only advantage I can see is that the author of the module saves adding a few accessors - at the expensive of an inflexible, complicated, do-it-all routine. Could you please expand on this? I guess I don't understand what is inflexible or complicated about the approach -- it seems simpler and more flexible from my (admittedly inexperienced) POV. Clearly, I'm missing something, and I'd like to better understand what it is. <-radiant.matrix-> A collection of thoughts and links from the minds of geeks The Code that can be seen is not the true Code "In any sufficiently large group of people, most are idiots" - Kaa's Law	[reply]

Replies are listed 'Best First'.

Re^2: Class attribute get/set approach flaws?
by radiantmatrix (Parson) on Nov 29, 2005 at 16:00 UTC

Another reason I don't like it is that, as presented, anyone can set and inspect any attribute. That includes typoed attributes, or just someone being "nasty".

Isn't this pretty much always true? Besides, I did mention that validation was a necessary part of implementing this concept: validation could easily include "you are(?:n't) allowed to modify this value".

Could you please expand on this? I guess I don't understand what is inflexible or complicated about the approach -- it seems simpler and more flexible from my (admittedly inexperienced) POV. Clearly, I'm missing something, and I'd like to better understand what it is.

<-radiant.matrix->
A collection of thoughts and links from the minds of geeks
The Code that can be seen is not the true Code
"In any sufficiently large group of people, most are idiots" - Kaa's Law

[reply]