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);
}
...
}
a) invariant = invariant, the meaning is described in the above and formerMB>> 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?
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
----------------------------------------------------------------------
