LB>> But is it a reason to prevent *good* coders (i don't argue here i'm
LB>> one) from using it disabling a feature ?
Yes, sometimes it is a reason, if it's reasonably hard to do right.
LB>> > b) put all the variable handling on the user (you will have to check
LB>> > *each* access to the class property, with no opt-out).
LB>>
LB>> Accessors are for special usage and won't be use in 100% of classes, i'm
LB>> convinced that developpers are able to choose to sacrifice a small
LB>> amount of performances or not.
That's not small amount. This class will be considerably slower - instead
of one C hash lookup there will be whole PHP procedure running. I don't
think I would be exaggerating if I'd talk about order of magnitude or
even two slower.
LB>> It's up to developpers to explain their work to other maintainers.
The problems is the developers themselves won't know, since there's no way
to know it.
LB>> Here again, it up to the developper to do a correct job. Infinite loops
LB>> and hard-to-catch magic are not reserved to accessors. A coder can
That's true, but this can not be an argument for introducing one more such
possibility.
LB>> Concerning class maintainers, in the current design they'll know if
LB>> accessors are called only after carefully reading the code of __get
LB>> __set and __call and after listing defines variables.
They know it after reading list of defined variables - any variable that
does not appear there will be passed to accessor.
LB>> In a python like design, they see the 'function __get' and they know
LB>> it will be called whatever object context is, that's a good point to
That is definitely not true - if you are in __get or any function called
from there, it would not be called.
LB>> I'll ask you to take this message as a 'feature request' and i'll try
LB>> to explay why i think the current design does not allow 'cleanly'
LB>> this feature.
Current design is slightly different feature. You can easily implement
your feature with current design, but you can not do the reverse. Thus,
the current design is more flexible, while not limiting you in what you
can do.
LB>> Yes but why hidding them from class users sight whereas they will
LB>> (virtually) use them in their programs through $object->varname ? I
LB>> mean the object interface should declare the "var $varname;" as this
LB>> var will exists in the class.
If you are using accessors, your intent is that this is not just variable
of the class like other variables of other classes, but a special one that
has some magic attached to it. It is a good way to distiguish "magical"
and "non-magical" class properties.
LB>> In my last message the variable 'bar' was public, a call to $foo->bar
LB>> would return null or false so the user know the variable value is
LB>> not already set. No need to create a __get()
Here you have lost me. So when is __get called? I was under impression
that you propose to call __get for every variable access. Is it so?
LB>> Yes, but and it's symptomatic of the current design problem (still
LB>> IMHO), and it will create more problems in php classes using the
LB>> feature as a way to intercept regular get/set/call.
I don't see how it is symptomatic to anything, since you made it out and
it doesn't really exist. As for intercepting "regular" calls - you
certainly can do it in current implementation, but, unlike your design,
you also have an option of *not* doing it.
LB>> The class developper will have to implement it's own name system to
LB>> check that the wanted property or method is allowed (the current
LB>> error reporting do it well already).
And in your scheme he wouldn't have to check? In your own code you wrote
'if' to check variable name. So I don't see what's the problem you have
with it.
LB>> This makes me confident in the idea that the current design mustn't be
LB>> used to intercept 'wanted' get/set/call but only as another name error
LB>> reporting system. ("error: you're trying to call a function that do not
LB>> exists", "error: the variable you requested does not exists").
That is not true, it can be used for both.
LB>> PHP already have an object property system, why building another one on
LB>> top of it making the developper work longer and harder to maintain ?
It does not make developper work longer and harder to maintain - at least
I see no proof of this thesis anywhere. It gives the developer a tool for
extending his control on the classes, and he is free to use or not to use
it.
LB>> In other languages the aim is just to give the developper a way to
LB>> 'overload' get set and call using the current class properties and
LB>> methods without having to build a new independant context for the
LB>> object.
I'm still not convinced that 'overloading' regular access is a good thing.
As well as I am not convinced, for example, that we need operator
overloading - in fact, I'm convinced that we are pretty well without it :)
LB>> 1. variables doesn't appear in class definition wheareas the user can
LB>> use them.
So? Documentation rules. Anyway if you use accessors you probably don't
want or cannot define it just as variables. You probably even don't know
the variables beforehand.
LB>> 2. the absolute need to create a private hashtable to handle variables
LB>> the user will use whereas he can't see them.
That supposing you want to keep them inside the object. Nothing, however,
prevents you from keeping it on disk, in SQL database or any other way
developer's vivid imagination can invent.
LB>> 3. the absolute need to create a getter for a setter
That's not entirely right, but I don't see it as an issue anyway.
LB>> 4. the need to recode this system everytime you wan't to use accessors.
This point I don't understand completely. What do you mean?
LB>> Simple :
LB>>
LB>> function __get($var)
LB>> {
LB>> // this is a recursive call to __get()
LB>> $temp = $this->someTestValue;
And here you get another call to __get, which in turn gets to this line
and produces another call to __get, which in turn... Am I missing
something?
LB>> There no way to mistake. And again 'if', 'for' and 'while' generate
LB>> bug when incorrectly used.
If you have in docs something that needs 'IMPORTANT' clause, this means
there's a well-paved way to a mistake. Otheriwse you wouldn't need any
'IMPORTANT' explanations ;)
LB>> The only argument i retain from your response is the performance one.
So I feel I must reiterate the second point: current scheme allows *both*
total and partial control over the access, at the marginal cost of one
hash lookup (you can even write object_get function yourself if you like
these names ;) and one variable in __get/__set functions. Your scheme
allows *only* total control at the cost of great class slowdown.
LB>> What you propose is a way to select variables which will invoque the
LB>> __get / __set. That's a good idea but moving them from the object to a
LB>> private hashtable destructurate the class conception.
Why? I don't see anything destroying class conception in private data.
There's a lot of very fine classes having private data.
LB>> class Foo {
LB>>
LB>> var $bar;
LB>>
LB>> getter $bar {...}
LB>> setter $bar($value) {...}
LB>> };
LB>>
LB>>
LB>> This is a feature request :)
Well, this was discussed... I'm not sure if there's a way to implement
these efficiently, but I'll put it in the 'to think about' box of my
brains, and maybe somebody other has ideas about this too. I'd propose you
to write a separate cleaner RFC (and check the list archives for similiar
proposals and their outcome).
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
