Hello,
PHP implements many features, and skips many features. I think the
rule of thumb needs to be that if a feature is implemented, finish
it.
For example, if you provide __get() and __set(), provide an
efficient way of handling the normal use case.
If you start triggering an E_NOTICE when an undefined variable is
accessed, then provide an easy way to access variables that may or
may not be set.
If you provide a __tostring() method, then finish it so that is gets
called when an object is cast to a string, concatenated with a
string, as well as being output with echo, print.
There are a lot of casual users of PHP. There are also the people
out there who are buying the Zend products, buying the MySQL support
contracts, using PHP at Yahoo! -- the people who have chosen to use
PHP OVER Java/.NET/Perl, because it is a great language -- the
people who need the completed features because they are running
multi-million-dollar businesses on this platform.
Take a step back and truly evaluate why someone in a demanding
situation might want every bit of performance and readability that
they can squeeze out of *existing* language features.
I'm not talking about adding hundreds of new features, or turning
PHP into the next java. It's about real business cases.
It's not about what YOU WOULD NOT use, it's about what a lot of
people need.
--
Best regards,
Jason Garber mailto:[email protected]
IonZoft, Inc.
Friday, May 12, 2006, 3:16:27 PM, you wrote:
igc> It seems to me this would be a great option to add. How difficult would it
igc> be? Would it take significant editing of the source code? I don't see the
igc> issue in adding it - seems like it would have plenty of places to be used.
igc> Though, if it is added, the name 'readonly' seems a little misleading. It
igc> gives off the idea of being able to set it, and not edit again, and not only
igc> being able to edit it inside the class.
igc> On 5/12/06, Hartmut Holzgraefe <
[email protected]> wrote:
Bastian Grupe wrote:
Blame my recent use of Java here ;-)
Well, I think the whole point of ppp is to having to use setters and
getters consistently.
i'm going to blame your use of Java for this one, ppp is way older
than the setter/getter fashion and as far as i remember the main
reason to introduce the setter/getter pattern into java was to
have a standard way for Java IDEs to provide access to Java Bean
properties in property dialogs in their GUI design tools
I personally wouldn't like to be able to access some members which are
private, and not others. It just *feels* wrong.
Think of it as a more fine grained permission system, like unix
file attributes. Reading and writing a property value are two
different operations and it makes sense to distinguish access
rights not only by ownership but also by type of operation.
And I don't know whether or not less typing is really a good argument in
this situation (think unreadable code in shortcut-ish programming
languages).
Less typing is not an argument by itself, else we'd all do APL
But less typing is less error prone (and no, plese *don't* mention
auto-completion here ;), it can be less readable, too, and in this
special case it spreads information that should be in one place.
Maintainability can become an issue, too.
Take a look at typical PHP class implementations: they have
all properties on top followed by the member functions. So to find
out whether a private property is really provite or whether it has
a getter or even a setter, too, i would have to browse the full
class code.
class example {
private $foo;
private $bar;
[... more properties ...]
function __construct() {...}
function __destruct() {...}
function getFoo() {...}
[... more code ...]
}
So $foo is readonly here and $bar is really private. Or wait,
maybe we have just overlooked getBar()?
With
readonly $foo;
on the other hand you have all the information in one place.
If you want to go the getter/setter path all the way then we
wouldn't need all the ppp stuff anymore alltogether, we would
just make everything private and have the getter and setter
decide (using instanceof on $this etc.) the access rights.
--
Hartmut Holzgraefe, Senior Support Engineer .
MySQL AB, www.mysql.com
Are you certified?
http://www.mysql.com/training/certification
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
http://www.php.net/unsub.php