[ I copy this to php-dev again, despite the fact that Ilker sent
this to me in private mail, because I want to promote the
concept of warnings for named accesses to _-members again.
Privacy in C++/Java style will raise a lot of issues on this list
again, if it is introduced to PHP. My proposal will have less
syntactial impact, and will better blend with the general style
of the language at this time.
]
Am Donnerstag, 6. Juni 2002 11:58 schrieb Ilker Cetinkaya:
> know how objects and inheritance is done in javascript (ecma
> respectively?). have you ever seen private members on objects
> of js?
In Javascript, each object is it's own class. You create new
objects basically by duplicating some initial object, that is,
Javascript's "new" is actually a "clone".
This is conceptually close to what PHP 4 does, where you can have
preinitialized member variables in an object, and where you can
at runtime add member variables to an object (and you could for
a short time even add member functions thanks to Andrej, I
believe). PHP 4 deviates from (I would even say "obscures this")
by not having an explicit "clone" operator (but PHP 4 implicitly
clones every time due to unexpected value-semantics).
Regarding the concept of private: Private member variables and
private member functions are a nuisance anyway in a language
where you can add members to an object at runtime.
Also, in it's wake the concept of "private" introduces a lot of
syntactic complexity as well, such as the need for "protected"
variables and functions, and a "friend" relationship between
classes. You will immediately see discussions around this issue
once privacy is introduced.
In Javascript-like languages, the same effect can be had by
simply issuing a warning whenever accessing a member variable or
member function with a name starting with "_" through a named
variable. That is, you would see warnings for
$a->_private_slot = 10;
$b = $a->_private_slot;
$c = $a->_private_function();
but not when accessing the same internally using $this:
$this->_private_slot = 10;
$b = $this->_private_slot;
$c = $this->_private_function();
A coder that must access private member variables and member
functions through a named variable (and there are a lot of
legitimate reasons for this, namely all metaprogramming
applications including debuggers, rpc proxies, serializers and
the like) can easily shut of this warning:
@$a->_private_slot = 10;
@$b = $a->_private_slot;
@$c = $a->_private_function();
will all execute warning-free, and clearly mark these statements
as violating the encapsulation-contract of conventional OO
programming, the same way a type-cast marks a violation of the
typing contract in C, C++ or other statically typed languages
(and there are a lot of legit reasons for that, too).
This implementation of private has several advantages, one of
them being that it is elective, another of them being that it is
the minimal syntactic extension of current PHP, and a third of
them being that it is compatible with current PEAR.
> namespaces?
> statics?
> consts?
These concepts do not contradict a dynamically (this is different
from loosely!) typed language concept.
> in closing, i have to admit that such a change would be a big
> issue in aspects of compatibility, juggling, parsing and
> object handling. therefore i'm sure it's not going to be
> realized.
> but still i'd desire it. just to be more stricty.
I suggest you try Java. You seem to want it.
Kristian
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
