Re: [PHP-DEV] classes, instances objects in ZE2
On Mon, Apr 08, 2002 at 05:18:07PM +0200, Marcus B?rger wrote: In my book, private is only of very limited use, because there always must be a way around it. So that book is your own meaning. No, an english ideom. http://www.m-w.com/cgi-bin/dictionary?va=book - in one's book : in one's own opinion I wrote: Introducing private (in C++) immediately called for the introduction of protected and friend, with protected being a mechanism to break privacy along the lines of the inheritance hierarchy and friend being a mechanism to break privacy across inheritance hierarchies, at compile time. meaning: A private variable is encapsulated, not accessible from outside the class. This is often to strong a protection and therefore the introduction of private variables usually triggers the introduction of mechanisms to subvert this privacy, with protected and friend being such mechanisms, and with proctected working along the inheritance hierarchy and friend across it, and with both mechanisms working only at compile time. You rephrase this, acknowledging my definitions: Yes it does call for it. But please do not use break. A private method is a method that cannot be used for inheritance. Thus you cannot implement it another way in a derived class/object. A protected method is a method that can be used for inheritance but is not accessible from other classes. A friend is a method/class that is allowed to handle private/protected members of another class (here breaking could be used). I wrote: Since PHP does many things at run time which C++ does at compile time, there must be a mechanism to break privacy at run time, which makes it pretty pointless to have private variables in the first place. meaning: mechanisms that subvert privacy at compile time are not sufficient or adequate for a language which does many things at run-time. I believe we agree on this, but cannot find direct evidence for that in your comment - do we agree on this particular point? You comment: Does not because inheritance does not necessary have to be implemented at compile time. For example, using aggregate. This can be handled using the same words at runtime, too. I get this as meaning: It is a bad idea to encode attributes of variables such as scope, visibility and accessability into the name of a variable and it would be better to use keywords for this. I concur with that. Traditionally, PEAR used the _ prefix to mark nonpublic slots in classes due to the lack of better mechanisms. So private as a keyword is probably better suited than my suggestion of using _ as a prefix to a variable name. I'd rather go for a warning that is being triggered whenever I access $a-_slot, but not when I access $this-_slot (Access to private object member). I could suppress this warning by writing $a-_slot as $a-_slot instead. We could do this by issuing an error instead of a warning (and we should)! So how would we break privacy at run-time, then? The -prefix for statemens only supresses warning messages, but does not allow continuation after error. If accessing a private slot in an object the regular way throws an error, we need a complete alternative syntax to be able to do this at run-time. I frown on this, because it adds a lot of complexity to the language. Issuing a warning instead allows us to use the statement prefix to access private slots in a class where we explicitly intend to do this, and still get notification for all accidental accesses to private slots. As already mentioned above we could use friend or referring to the other OO discussion going on we could use aggregation to achieve this. So there is no need for get/Set_private(). protected and friend are commonly compile-time mechanisms, so they are not sufficient for us, unless you refer to an uncommon case where protected() and friend() are being used as functions on existing objects or classes in order to modifiy accessibility attributes after object instantiation. Kristian -- Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel Tel: +49 431 386 435 00, Fax: +49 431 386 435 99 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] classes, instances objects in ZE2
At 10:47 09.04.2002, Kristian Koehntopp wrote: On Mon, Apr 08, 2002 at 05:18:07PM +0200, Marcus B?rger wrote: In my book, private is only of very limited use, because there always must be a way around it. I skipped the first part because i think we are now talking about the same thing here. I find it very hard when discussing such things and all people use phrases as they like instead of their accepted meaning. I get this as meaning: It is a bad idea to encode attributes of variables such as scope, visibility and accessability into the name of a variable and it would be better to use keywords for this. I concur with that. Traditionally, PEAR used the _ prefix to mark nonpublic slots in classes due to the lack of better mechanisms. So private as a keyword is probably better suited than my suggestion of using _ as a prefix to a variable name. Keywords are better then implicit definitions. Remember the discussion about __get_x() going on now, too. I'd rather go for a warning that is being triggered whenever I access $a-_slot, but not when I access $this-_slot (Access to private object member). I could suppress this warning by writing $a-_slot as $a-_slot instead. We could do this by issuing an error instead of a warning (and we should)! So how would we break privacy at run-time, then? The -prefix for statemens only supresses warning messages, but does not allow continuation after error. If accessing a private slot in an object the regular way throws an error, we need a complete alternative syntax to be able to do this at run-time. I frown on this, because it adds a lot of complexity to the language. Issuing a warning instead allows us to use the statement prefix to access private slots in a class where we explicitly intend to do this, and still get notification for all accidental accesses to private slots. I would like to have private, protected and public which can be easily done by adding one single flag to the members of an object. With friends implementation may be much harder because each class or even object has to have a friends list. For classes or even objects this could be a simple list. But when allowing freinds for functions or methods its getting real hard i suppose. As already mentioned above we could use friend or referring to the other OO discussion going on we could use aggregation to achieve this. So there is no need for get/Set_private(). protected and friend are commonly compile-time mechanisms, so they are not sufficient for us, unless you refer to an uncommon case where protected() and friend() are being used as functions on existing objects or classes in order to modifiy accessibility attributes after object instantiation. Why are they not sufficient? And why not having friend and protected working a bit different than in C++. Just because many people use C++? That would be a bad reason! There is nothing that forbids us to save information generated for the compiler tree into our classes/objects and using them at run time. By the way: In C++ you have dynamic_cast operator which works at run time using rtti , too. Kristian marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] classes, instances objects in ZE2
On Tue, Apr 09, 2002 at 11:11:58AM +0200, Marcus B?rger wrote:
Keywords are better then implicit definitions.
Agreed.
I would like to have private, protected and public which can
be easily done by adding one single flag to the members of an
object.
So how would you set or reset these flags at run-time?
With friends implementation may be much harder because each
class or even object has to have a friends list.
Why would friend be necessary in the first place, when you
simple could
class A {
private $slot;
}
class B {
function do_with_an_A($someA) {
$someA-slot = 10; // I know it is private and I intend to break it.
}
}
friend is just a compile-time declaration of a list of classes
for which you intend to break privacy, and if you can to it
anyway at run-time, you do not need such a declaration.
protected and friend are commonly compile-time mechanisms, so
they are not sufficient for us, unless you refer to an uncommon
case where protected() and friend() are being used as functions
on existing objects or classes in order to modifiy accessibility
attributes after object instantiation.
Why are they not sufficient?
Because, again, they require a complete and finished declaration
of privacy breakage at compile time. That is lacking dynamism,
and for some more advanced applications such breakage at
run-time would be extremely handy.
There is nothing that forbids us to save information generated
for the compiler tree into our classes/objects and using them
at run time.
using would not be enough here, modifying or ignoring
would be called for.
Kristian
--
Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel
Tel: +49 431 386 435 00, Fax: +49 431 386 435 99
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] classes, instances objects in ZE2
At 11:34 09.04.2002, Kristian Koehntopp wrote:
On Tue, Apr 09, 2002 at 11:11:58AM +0200, Marcus B?rger wrote:
Keywords are better then implicit definitions.
Agreed.
I would like to have private, protected and public which can
be easily done by adding one single flag to the members of an
object.
So how would you set or reset these flags at run-time?
I DO NOT WANT TO! If design is correct i do not have to!
With friends implementation may be much harder because each
class or even object has to have a friends list.
Why would friend be necessary in the first place, when you
simple could
class A {
private $slot;
}
class B {
function do_with_an_A($someA) {
$someA-slot = 10; // I know it is private and I intend to break it.
}
}
friend is just a compile-time declaration of a list of classes
for which you intend to break privacy, and if you can to it
anyway at run-time, you do not need such a declaration.
You simply ignore every information available to code execution here.
Then i do not have to say anything about private and so on.
There is a difference of programming in small and in teams. If working
alone i would not need to say anything about visibility. But when working
in teams i would like to make the defined and agreed or published method
and member subset public. So only the programmer that is responsible
for a class must know about the private members. The protected members
are for the group that works on a class hierarchy.
I think this is a key discussion for PHP. Do we want PHP to be acceptable
for big projects or not?
protected and friend are commonly compile-time mechanisms, so
they are not sufficient for us, unless you refer to an uncommon
case where protected() and friend() are being used as functions
on existing objects or classes in order to modifiy accessibility
attributes after object instantiation.
Why are they not sufficient?
Because, again, they require a complete and finished declaration
of privacy breakage at compile time. That is lacking dynamism,
and for some more advanced applications such breakage at
run-time would be extremely handy.
There is nothing that forbids us to save information generated
for the compiler tree into our classes/objects and using them
at run time.
using would not be enough here, modifying or ignoring
would be called for.
Again i want to use them not modifying or ignoring. And if you
do not use private and such your classes are all friends. Or in other
words you can simply leave such modelling aspects aside.
Kristian
--
Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel
Tel: +49 431 386 435 00, Fax: +49 431 386 435 99
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] classes, instances objects in ZE2
- Original Message - From: Marcus Börger [EMAIL PROTECTED] Subject: Re: [PHP-DEV] classes, instances objects in ZE2 I think this is a key discussion for PHP. Do we want PHP to be acceptable for big projects or not? +1 on that. And +1 on discussion if there will be some kind of compiler( not sure if +it is possible but what about comilation to Java bytecode or .net MSIL - I read somewhere that ADA can be comiled to Java bytecode, why not have PHP compiled for it.). Regards, Andrey Hristov -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] classes, instances objects in ZE2
Marcus Börger wrote:
- we have private, what about final, public, protected and
abstract (can we remove/hide a method from an object)?
Do we in ZE2? What use it is?
In my book, private is only of very limited use, because there
always must be a way around it.
Introducing private (in C++) immediately called for the
introduction of protected and friend, with protected being a
mechanism to break privacy along the lines of the inheritance
hierarchy and friend being a mechanism to break privacy across
inheritance hierarchies, at compile time.
Since PHP does many things at run time which C++ does at compile
time, there must be a mechanism to break privacy at run time,
which makes it pretty pointless to have private variables in the
first place.
I'd rather go for a warning that is being triggered whenever I
access $a-_slot, but not when I access $this-_slot (Access to
private object member). I could suppress this warning by writing
$a-_slot as $a-_slot instead.
Providing stronger privacy would only force the addition of even
more syntactic candy (such as a get_private($o, $slot) and
set_private($o, $slot)). Functions to break privacy are needed
in order to write Metafunctionality such as a serialization
agent, or a RPC proxy like the Soaping mixin class I introduced
in another mail to this list.
- do we allow to reduce visability (replace protected by
private as long as we don't have it):
class A {
public function f()..
}
class B extends A {
protected function f()...
}
Same reasoning as above. Make it a warning, do not delve into BD
language realms. PHP does things at run time, because we are in
the rapid prototyping area and flexibility comes before compile
type checking and static bindings. And anyway, class != type in
PHP.
Kristian
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] classes, instances objects in ZE2
At 15:36 08.04.2002, Kristian Köhntopp wrote:
Marcus Börger wrote:
- we have private, what about final, public, protected and
abstract (can we remove/hide a method from an object)?
Do we in ZE2? What use it is?
In my book, private is only of very limited use, because there
always must be a way around it.
So that book is your own meaning. I do more like accepted books on
computer language theory (for OO languages there is only one book:
A Theory on Objects; Martin Abadi, Luca Cardelli, Springer).
Introducing private (in C++) immediately called for the
introduction of protected and friend, with protected being a
mechanism to break privacy along the lines of the inheritance
hierarchy and friend being a mechanism to break privacy across
inheritance hierarchies, at compile time.
Yes it does call for it. But please do not use break.
A private method is a method that cannot be used for inheritance.
Thus you cannot implement it another way in a derived class/object.
A protected method is a method that can be used for inheritance but
is not accessible from other classes. A friend is a method/class that
is allowed to handle private/protected members of another class (here
breaking could be used).
Since PHP does many things at run time which C++ does at compile
time, there must be a mechanism to break privacy at run time,
which makes it pretty pointless to have private variables in the
first place.
Does not because inheritance does not necessary have to be implemented
at compile time. This can be handled using the same words at runtime, too.
The one reason for handling inheritance at compile time is that you can
easier achive type strictness at compile time (but like C++ we don't have
that).
I'd rather go for a warning that is being triggered whenever I
access $a-_slot, but not when I access $this-_slot (Access to
private object member). I could suppress this warning by writing
$a-_slot as $a-_slot instead.
We could do this by issuing an error instead of a warning (and we should)!
Providing stronger privacy would only force the addition of even
more syntactic candy (such as a get_private($o, $slot) and
set_private($o, $slot)). Functions to break privacy are needed
in order to write Metafunctionality such as a serialization
agent, or a RPC proxy like the Soaping mixin class I introduced
in another mail to this list.
As already mentioned above we could use friend or referring to the
other OO discussion going on we could use aggregation to achieve
this. So there is no need for get/Set_private().
- do we allow to reduce visability (replace protected by
private as long as we don't have it):
class A {
public function f()..
}
class B extends A {
protected function f()...
}
Same reasoning as above. Make it a warning, do not delve into BD
language realms. PHP does things at run time, because we are in
the rapid prototyping area and flexibility comes before compile
type checking and static bindings. And anyway, class != type in
PHP.
Rapid prototyping does not necessary need to have bad design. And
of cause when not using private/protected you can do dirty prototyping
just like without it - BUT you can do really good design. And i thought
we all would like PHP to become *the* solution for web applications.
Kristian
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] classes, instances objects in ZE2
I agree with Kristian here; it is quite common to need to break
the protected/privacy rules when the class hierarchy is badly designed.
I'm referring to Delphi here where code like this is required because
someone didn't make something public when they should have.
It's a double issue: 1) is that the class is badly designed, 2) is
that this hack is even possible.
/* psuedo code */
class ImageList {
protected HImageList; /* should be public, or have a getter */
};
// In some other code that uses winapi and needs the handle
class ImageListHack {
public HImageList;
};
handle = ((ImageListHack)imlist)-HImageList;
On 09/04/02, Marcus Börger [EMAIL PROTECTED] wrote:
At 15:36 08.04.2002, Kristian Köhntopp wrote:
Introducing private (in C++) immediately called for the
introduction of protected and friend, with protected being a
mechanism to break privacy along the lines of the inheritance
hierarchy and friend being a mechanism to break privacy across
inheritance hierarchies, at compile time.
Yes it does call for it. But please do not use break.
A private method is a method that cannot be used for inheritance.
Thus you cannot implement it another way in a derived class/object.
A protected method is a method that can be used for inheritance but
is not accessible from other classes. A friend is a method/class that
is allowed to handle private/protected members of another class (here
breaking could be used).
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] classes, instances objects in ZE2
Since there is a lot of discussion going on, i had some thoughts.
Clearing some terms before:
class = template for objects/instances
a class holds a list of methods and knows about its parents
a class can have static members/methods which can be used without
creating an object/instance
interface = a collection of methods and members that must be
implemnted
in a class/object (for example: java uses this to emulate
missing multiple
inheritance)
most languages do not allow code in an interface. for me i like
the idea
of having static members/methods in interfaces and the dynamic
part
can be done by using properties
- leads to operator
$obj-implements('interface-name')
member = a variable bound to an instance/object (like a record
member)
instance = instance of a class with pointer to method table of
class
and memory for members (non static class members) for those
who
do not like pointers: name it class identifier and supply a
hashtable
to find the class.
object = instance with private method table that can differ from the
method table of the class it was made of (if made from class)
in other words an object can modify/override methods without
changing any class if so it is no longer boundable to any
class
property = a pseudo member realised by a getter and a setter
method
and now some questions:
- we have no interfaces (as far as i know)
- we have classes and instances not objects (our instances cannot
change methods, can they? but they can add members)
- we have private, what about final, public, protected and abstract
(can we remove/hide a method from an object)?
- do we allow to reduce visability (replace protected by private as
long as we don't have it):
class A {
public function f()..
}
class B extends A {
protected function f()...
}
and some more:
multiple inheritance = class A extends B, C
the problem is that inheritance graph now is no longer a tree
- MANY PROBLEMS
current docu does not allow A:B:X instead it is allways 'A:B':X
therfore you cannot
access any X in C if B also has X (or does what is said about : do
apply only for
namespaces - then its confusing!)
i would appreciate having interfaces with code!
class A {
function f(string $s) {
echo $s\n;
}
function f(string $s1, string $s2, string $s3='')
{
f($s1.$s2.$s3);
}
function f(array $a) {
foreach($a as $s) f($s);
}
}
class B extends A {
function f(array $a) {
foreach($a as $idx=$s) f($idx, ':',
$s);
}
}
A.f(string) - executed
A.f(string, string, string) calls A.f(string)...
A.f(string, string) uses A.f(string, string, string)...
A.f(array) calls A.f(string)...
B.f(string) calls A.f(string)...
B.f(string, string, string) calls A.f(string, string,
string)...
B.f(string, string) uses B.f(string, string, string)...
B.f(array) calls A.f(string, string, string)...
same using interfaces:
interface L {
abstract f(string $s);
}
interface S { // interface S implemts L should work, too
f(string $s) {
echo $s\n;
}
function f(string $s1, string $s2, string $s3='')
{
f($s1.$s2.$s3);
}
f(array $a) {
foreach($a as $s) f($s);
}
}
interface T extends S {
f(array $a) {
foreach($a as $idx=$s) f($idx, ':',
$s);
}
}
class A implements S,L {
}
class B extends A implements T { // implements L
because A implements L
}
A.f(string) calls S.f(string) - executed
(1) A.f(string, string, string) calls S.f(string,string,string)
calls A.f(string)
A.f(string, string) uses A.f(string, string, string)
(1) A.f(array) calls S.f(array) calls A.f(string)...
B.f(string) calls A.f(string)
B.f(string, string, string) calls A.f(string, string,
string)
B.f(string, string) uses B.f(string, string, string)
(1) B.f(array) calls T.f(array) calls B.f(string, string,
string)
so i used class info prior to interface info (runtime)
when interface code is done at compile time the result differs in
*:
(2) A.f(string,string,string) calls S.f(string,string,string)
calls *S.f(string) - executed
(2) A.f(array) calls S.f(array) *calls S.f(string) -
executed
(2) B.f(array) calls T.f(array) calls
*S.f(string,string,string) calls S.f(string) -
executes
that leads to above code doing (2) and the following code
using *needs* performing (1):
interface S {
f(string $s) {
echo $s\n;
}
}
interface S2 needs S {
function f(string $s1, string $s2, string $s3='')
{
f($s1.$s2.$s3);
}
}
interface S3 needs S {
f(array $a) {
foreach($a as $s) f($s);
}
}
interface T extends S3 {
f(array $a) {
foreach($a as $idx=$s) f($idx, ':',
$s);
}
}
class A implements S,S2,S3 {
}
class B extends A implements T {
}
parametric inheritance = class A(type-param) ...
mostly resolved by precompilers to full class-sourcecode
i think we do not need this
BUT we will have loose-types in ZE2 so it would make sence to have
it
BUT Then we should also have methods with same name but different
parameter signature
message-handlers?
marcus
