Posted by Steve on 04/20/07 23:07

| Ok, now, at last I think I've got it. _set; __get; etc. are native
| functions. They exist transparently at all times without requiring you
to
| implement them. Member vars with a public interface are in effect set end
| errr, getted, gotten begetted, begotten whatever, via these normaly
| transparent functions. Once you implement these member functions yourself
| you are in effect 'overloading' these normaly 'transparent' equivelants.
| Therefore, if you access a public member property, and have these
functions
| defined yourself, php effectively ignores your definition and uses it's
own
| transparent equivelants with regard to those member vars with public
| interfaces.

that's certainly one interpretation where the evidence won't contradict the
theory you've arrived upon. however, it is wrong. overloading would mean
somehow that php knows to what function __set/__get applies. this is not the
case. again, the important part is that __set/__get only fire if you try to
access a member on an object that does NOT exist in the class. that again
means that there is no association between php and your defined interfaces -
except to say that php gives you a means to detect when someone is trying to
muck with your object without going through your defined interfaces...via
__set/__get. to which your response should be to thow an error.

does that make the distinction more clear?

| So, when you define __set(), and __get(), the engine will only allow you
to
| use the 'overloaded' functions on private, or protected interfaces (I'm
| guessing about protected, I haven't tried them). Therefore, in effect,
| __get() and __set() __are__ the interfaces in and of themselves.

no. they are a means to let the class know someone is __getting or __setting
a property that does not exist in your object's definition.

| An error or warning would be to alert you to the fact that your
implemented
| __get() and or __set() are not being utalized by the engine, and it uses
| it's own native versions.

no.

| Now I understand why I just couldn't grasp what was being meant by
| 'overload' in the context of these functions.

if that were going on. in php, you can't truly overload. you can extend and
replace a function of the base, but this is technically called 'overriding',
not 'overloading'. :)

as it is here, neither of this is going on.

| Sorry about the verbosity, but if I have anything incorrect I'd rather it
| not be overlooked ;)

no worries.

| Thank you very much for your patience. My grey putty is slow to take on
new
| shapes sometimes, perhaps more than sometimes. :]

i think you appologize too much. :)

we are *all* learners. we'll help eachother along.

cheers.

[Back to original message]