Morning,
> I think it's a bug in APC. Each extension has its own slot, by
> allocated slot number, and should never touch other slots (unless it
> has some protocol to talk to the extension which owns other slot). So
> touching slot that is not owned by the code is a bug like touching
> unallocate
class TableSelectExplainBuilder extends TableSelectBuilder
{
static protected function buildSelectQuery()
{
return "EXPLAIN ".parent::buildSelectQuery();
}
}
Why not do static:: instead of parent:: here?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://w
Now, let's say the "base" class is called "Entity".
And let's say I have an inherited class called "Client":
Abstract Class Entity {
function read()
{}
function delete()
{}
...
}
Class Client extends Entity
{
public $id;
public $first_name;
With static:: you are not able to call method of parent with the same name.
Dmitry.
> -Original Message-
> From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 21, 2007 12:03 PM
> To: Michael Lively
> Cc: Dmitry Stogov; 'Marcus Boerger'; 'Lukas Kahwe Smith';
> '
Hello Dmitry,
this is a good idea imo. It sounds like the most natural solution - to me.
marcus
Thursday, September 20, 2007, 12:04:04 PM, you wrote:
> From technical point of view it is possible to propagate LSB with self::,
> parent::, and static:: and not with CLASS::.
> I think it may be
>__CLASS__ returns name of the class, get_parent_class() is the name of
>parent class, those are entirely different things, nothing to do with
>compiler/run time. Class always has one name and one parent or none.
Sorry, I meant:
__CLASS__
and
get_class($this)
They are both different things, and
I mean, when you want to go upwards, to reach an ancestor class.
You can't go upwards, because there's no upwards for classes. You can
use the information you already have, via static:: and function that is
analogous to it for static and get_parent_class for non-static.
But it could also me
With static:: you are not able to call method of parent with the same name.
Ah, I see you point. I'm starting to dislike all this idea of "let's
have an object without really having an object"... It's becoming messy
now - we now need to start to invent all kinds of complex propagation
rules f
>It's becoming messy now - we now need to start to invent all kinds of
>complex propagation rules for it in parallel with the true object
>propagation rules. Why not just have an object then?
Because if you could only see the incredible number of "get_class($this)"
and of "if(__CLASS__!=get_class(
