in reply to Re: Class attribute get/set approach flaws?
in thread Class attribute get/set approach flaws?

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
  • Comment on Re^2: Class attribute get/set approach flaws?