Re: [PHP-DEV] Why i believe we need final

[Marcus Börger]

At 22:05 23.01.2003, Marcus Börger wrote:

The current OO implementation ( ... bla ... ) final ( ... bla ... )


I just updated the patch and it is getting a bit smaller due to latest engine
changes. I also moved the check code from zend_language_parser.y into
zend_compile.c (as suggested  by...i think it was andi).

http://marcus-boerger.de/php/ext/ze2/ze2-final-30214.diff.txt

regards
marcus


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Why i believe we need final

[Marcus Börger]

At 10:34 30.01.2003, Stanislav Malyshev wrote:

MB>> If you want real life examples (and surely it seems you will never
MB>> trust me) get yourself a book from scott meyers (going to my

I would certainly trust you if you gave me an example. Marcus, I'm not
here to personally attack you. I just do not see the value of this
feature. If you do - why not enlighten me?


I was giving up because i was out of timeand i did not felt
personally attacked. I felt it makes no sense to argue anymore.

Hm.. in my last example the containers i tried to present an idea on which
unluckily you had another point of view.

For another try i guess one (if not the most important one) of the reasons
why i would like to have final is to hinder users to missuse classes defined
in extensions (adt,domxml,...) in userland. The other important reason is
the thing with the invariant functions.

For the invariant functions consider a mutex: It has enter() and leave()
methods. And there is really no need to override or redeclare them. So
i would like to declare them final since we do not have another possibility
to express invariants.

Besides that most other oo features do not make sense for php since we
do not have a typed language. In that we are on the same way.

marcus


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Why i believe we need final

[Stanislav Malyshev]

MB>> If you want real life examples (and surely it seems you will never
MB>> trust me) get yourself a book from scott meyers (going to my

I would certainly trust you if you gave me an example. Marcus, I'm not 
here to personally attack you. I just do not see the value of this 
feature. If you do - why not enlighten me? I submit that if an idea has a 
value, there ought to be a way to show others that value - or at least to 
try it, including providing examples on how this idea should be useful. 
Referring me to textbooks on OO is not going to prove anything - I had my 
OO classes and I know what OO is. I just don't see how 'final' can be 
really useful in PHP - not in OO-textbook theorteical way, but in 
practice. And I believe there are more people that do think so - 
otherwise I would have been enlightened already by someone who sees the 
practical use of it. 
-- 
Stanislav Malyshev, Zend Products Engineer   
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.109



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Why i believe we need final

[Marcus Börger]

At 09:46 29.01.2003, Stanislav Malyshev wrote:

MB>> Sure it cannot because insert cannot. The problem and the error you did
MB>> above is that you split an operation into two. Your real operation is
MB>> insert_with_password and that is different from insert. Again insert 
is an

That's the whole point of OO - to allow overloading the same operation, so
even classes that do not know about implementation details could use it.

MB>> as a member and not as a base class. Maybe it is now a good thing to
MB>> have a generalised container interface and declare insert in the 
container
MB>> implementations final. Highly specialised containers would then inheritd

I do not see why should container interface be final.

MB>> A class that is derived from a concrete container may in some container
MB>> implementations have final functions. For example whatever inherits a 
fifo

Still have no explanation why anyone would need it. Just to disallow
overriding "because we can"? I see no added value in that.

MB>> If you have another insert implementation in a class than you
MB>> missused inheritance. If the operation is different than your derived
MB>> class is no for example no longer a fifo. Instead it uses a fifo.

Implementation can be different and still be a fifo. That depends on
overriding implementation.

Again, I still have yet to see any example where the proposed 'final'
plays substantial role and not just is there because 'maybe someone might
want to use it'.


Hey YOU are the example you are looking for. Think i earn money by designing
class and data models and in that i know that i cannot modell the world and as
a result i create modells which are no "all-in-one devices suitable for 
everything"
(german: eier-legende-wollmilchsau) and even capable of beeing missused for
that by inheritance. And at those points where i know of the simplications and
restrictions and compromises i made i *may* decide a function to be "final".

If you want real life examples (and surely it seems you will never trust 
me) get
yourself a book from scott meyers (going to my bookshelf) "effective c++" and
"more effective C++" and read something about programmingand remeber
C++ has no final it only has virtual and non virtual (and it also has 
abstract with
default implementation (the other discussion where i said is possible and 
valuable
to think about)). If you don't like C++ get you a theory book or any good book
about another language(written by someone who has understood OOP).

Sorry but i guess the discussion does not make any more sense.

marcus


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Why i believe we need final

[Stanislav Malyshev]

MB>> Sure it cannot because insert cannot. The problem and the error you did
MB>> above is that you split an operation into two. Your real operation is
MB>> insert_with_password and that is different from insert. Again insert is an

That's the whole point of OO - to allow overloading the same operation, so 
even classes that do not know about implementation details could use it. 

MB>> as a member and not as a base class. Maybe it is now a good thing to
MB>> have a generalised container interface and declare insert in the container
MB>> implementations final. Highly specialised containers would then inheritd

I do not see why should container interface be final. 

MB>> A class that is derived from a concrete container may in some container
MB>> implementations have final functions. For example whatever inherits a fifo

Still have no explanation why anyone would need it. Just to disallow 
overriding "because we can"? I see no added value in that. 

MB>> If you have another insert implementation in a class than you
MB>> missused inheritance. If the operation is different than your derived
MB>> class is no for example no longer a fifo. Instead it uses a fifo.

Implementation can be different and still be a fifo. That depends on 
overriding implementation.

Again, I still have yet to see any example where the proposed 'final' 
plays substantial role and not just is there because 'maybe someone might 
want to use it'.

-- 
Stanislav Malyshev, Zend Products Engineer   
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.109




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Why i believe we need final

[Marcus Börger]

At 15:52 27.01.2003, Stanislav Malyshev wrote:

MB>> Consider you defined a container (list, vector what ever) and want
MB>> to derive from it. Then there is *really*no* need to override methods
MB>> like "insert" or "remove". You may want to have additional things like
MB>> "insert_if" or whatever. But for the container part "insert" must stay as
MB>> it is and that requires static binding.

Well, if there is *really no need*, why one would override it? Obviously,
if one overrides it, there's a need? I don't see why container writer
should care if anyone overrides the method. Could you bring a real example
where one needs non-overridable methods? Only thing I can think of are
various Java security classes (like class loaders, etc.) which if you
succeed to override various checking hooks may lead to trouble. But we
don't have such things in PHP...
For example, what if I want to create "secure container", where insert can
be done only after you called password() function for the container with
right password? Your 'finalized' container would not allow me to do it.


Sure it cannot because insert cannot. The problem and the error you did
above is that you split an operation into two. Your real operation is
insert_with_password and that is different from insert. Again insert is an
invariant function for the container. But now you should have a container
as a member and not as a base class. Maybe it is now a good thing to
have a generalised container interface and declare insert in the container
implementations final. Highly specialised containers would then inheritd
the interface and use a member of a less specialised container:

class container_interface {
abstract function insert();
abstract function delete();
abstract function get();
}

class fifo extends container_interface {
final function insert($elem) { ... }
final function delete($elem) { ... }
final function get() { ...  return ... }
}

class secure_container extends container_interface {
private $m_fifo;

function __construct()
{
$this->m_fifo = new fifo();
}

function insert($elem, $user, $passwd)
{
// check password match or emit error
$m_fifo->insert($elem);
}

...
}





MB>> And here comes "final" as it allows to emulate static binding with
MB>> dynamic binding. If you declare a function "final" it is invariant
MB>> against inhertance starting from that point in the inhertance tree. In

Could you explain what is "invariant against inhertance"? What should
happen if I define function with the same name in derived class - is this
a compile error?


a) invariant = invariant, the meaning is described in the above and former
mail (- it's about oo programming techniques (oh i remeber i wrote that in
last mail already)). Again invariant against inheritance means that you
have a function that is not to be overloaded since the operation is not
modified by inheritance.

A general container has an abstract insert operation or in full it has an
abstract interface which is outlined by a collection of abstract functions. A
concrete container consists of something that uses the inherited abstract
interface to implement a specific container (list, array, stack, fifo, ...).

A class that is derived from a concrete container may in some container
implementations have final functions. For example whatever inherits a fifo
must insert elements at the top and get elements from the top. And here
it is of no importance what you store in the derived classes.

If you have another insert implementation in a class than you missused
inheritance. If the operation is different than your derived class is no for
example no longer a fifo. Instead it uses a fifo. Back to oo design there
is a very important rule: "is a" = (public) inheritance differs from "has a"
= member (or something we do not have in php).

Remeber one of our earlier discussions: I liked information hiding but it
was diclined because it conflicts "is a". So in other words you insisted on
pure inheritance. Now i just described one step beyond.


b) What should happen?
- In java you cannot redeclare a final function.
- In C++ a function is an invariant if it is *not* declare virtual. Here 
you can
  redeclare it at will (but hopefully you know what that means and avoid it).

Since we cannot have non virtual functions and discussing final here i am
(obviously) in favor of the java solution (in real life the above is one of 
the few
points i dislike in c++).

regards
marcus


--
--
Marcus Börger - Looking for all sorts of freelance work - just ask...

Did i help you? Consider a gift:
http://www.amazon.de/exec/obidos/wishlist/ho722v0rg1u0
--

Re: [PHP-DEV] Why i believe we need final

[Stanislav Malyshev]

MB>> Consider you defined a container (list, vector what ever) and want
MB>> to derive from it. Then there is *really*no* need to override methods
MB>> like "insert" or "remove". You may want to have additional things like
MB>> "insert_if" or whatever. But for the container part "insert" must stay as
MB>> it is and that requires static binding.

Well, if there is *really no need*, why one would override it? Obviously, 
if one overrides it, there's a need? I don't see why container writer 
should care if anyone overrides the method. Could you bring a real example 
where one needs non-overridable methods? Only thing I can think of are 
various Java security classes (like class loaders, etc.) which if you 
succeed to override various checking hooks may lead to trouble. But we 
don't have such things in PHP... 
For example, what if I want to create "secure container", where insert can 
be done only after you called password() function for the container with 
right password? Your 'finalized' container would not allow me to do it. 

MB>> And here comes "final" as it allows to emulate static binding with
MB>> dynamic binding. If you declare a function "final" it is invariant
MB>> against inhertance starting from that point in the inhertance tree. In

Could you explain what is "invariant against inhertance"? What should 
happen if I define function with the same name in derived class - is this 
a compile error?

-- 
Stanislav Malyshev, Zend Products Engineer   
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.109



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Why i believe we need final

[Marcus Börger]

The current OO implementation of ZE2 only allows dynamically
binding of methods. That is all functions are inherited like if they
were declared "virtual" in other languages.

The thing we do not have is static binding of methods. First one
could argue that we do not have a type system and 

On the other hand there is a need for static binding since it allows
us to declare functions that are *invariant* against inheritance.
That is especially usefull for things like a standard class library (what
ADT might become hopefully) or even your own standard class
collection.

Consider you defined a container (list, vector what ever) and want
to derive from it. Then there is *really*no* need to override methods
like "insert" or "remove". You may want to have additional things like
"insert_if" or whatever. But for the container part "insert" must stay as
it is and that requires static binding.

And here comes "final" as it allows to emulate static binding with
dynamic binding. If you declare a function "final" it is invariant
against inhertance starting from that point in the inhertance tree. In
other words it is even more powerfull than pure static binding and as
a side effect it eliminates the problem that someone overrides erm
redeclares a static bound function beeing inherited.

A patch can be found here:
http://marcus-boerger.de/php/ext/ze2/

regards
marcus

p.s.: It would be nice to reach a consensus here soon because i want
to start another extension to the OO model - if you read between the
lines you may guess but it'l have to wait...





--
--
Marcus Börger - Looking for all sorts of freelance work - just ask...

Did i help you? Consider a gift:
http://www.amazon.de/exec/obidos/wishlist/ho722v0rg1u0
--


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php