|
|
Posted by Steve on 04/20/07 15:36
| I would have something like a switch statement that made sure the
| variables the user is trying to set are valid and runs the appropriate
| private function to validate.
i understand that. what i'm saying (right from the php docs), is that __set
is ONLY executed in your class by php when an interface that does NOT EXIST
as part of your class is accessed. same thing with __get.
| For example, I might define
| "description" as a property which will then exists in the switch list
| in the __set function which will then in turn call set_description
| which would carry out any validation and store the value in something
| like _description. They only thing I really achieve by doing this is
| avoiding the user having to call set and get functions, I think it's
| worth it though.
yes, and it is the *correct* approach since you should be able to scope the
interfaces as well. HOWEVER PHP DOES NOT SUPPORT THIS. sorry, was i speaking
loudly? :) in the future, perhaps they will. there are many requests out
there now for such support.
| > add_item could/would be the best place to add validation for $item, imo.
| > however, you still can't protect $item from someone changing it's values
| > after add_item has had it's way with it.
|
| I have to disagree with that. It feels most confortable with me to do
| validation in the Item object, since in my mind the logic and
| behaviour of that object should be contained within itself rather than
| creating a dependency on the component object. I'm open to persuation
| though.
given the way you showed $item, i stated my opinion. if you put
getters/setters on $item, i'd not have suggested otherwise and we'd have no
dispute. as it is currently in php (esp. earlier versions), you cannot
guarantee the value of ANY interface variable that is public in scope.
therefore, i usually only fuss about validation before i'm going to do
something critical with what the object represents.
make sense?
Navigation:
[Reply to this message]
|