On Wed, 2009-02-04 at 08:58 +1100, Chris wrote: > >> the question is what is __set() doing, if it's throwing an exception > >> for undefined properties then obviously it with 'blow up'. > > > > > > > > But why should __set() even be called if I'm accessing the property > > directly? This seems stupid. > > > > $this->oraclecustomerid = 1122; > > > > should NOT be the same as > > > > $this->set_oraclecustomerid(1122); > > > > The second one I agree should call __set(), but the first one should NOT > > be triggering __call() or __set() > > Yes it should. > > http://www.php.net/manual/en/language.oop5.overloading.php#language.oop5.overloading.members > > __set() is run when writing data to inaccessible members. > > if it's a protected/private variable, it'll call __set. > > If it's a variable that doesn't exist, it'll call __set. >
Let me rephrase that. I see now that it is designed that way, but I think the logic is erroneous. While I'm sure this argument/discussion is all for naught now, I believe that a straight assignment of a value to a variable, SHOULD NOT do any behind the scenes magic __set(). It should just do it. Otherwise, what's the point of being able to "set" a property/variable both ways? One gives no benefit over the other and as illustrated decreases flexibility. It appears it will work if I change my property to public, but I don't want them exposed like that. *sigh* Bottom line is there should be a create_property($name, $value = null, $type = 'protected') function/method that I can call to do what I'm trying to do. I assume unset($this->foo); works. So therefore, I can check for existence of a property, and consequently remove a property, but I cannot create a property.
