Jochem Maas wrote:
Morten Rønseth wrote:
Hi,
I just tried the example code at
http://www.zend.com/lists/php-dev/200307/msg00244.html using PHP 5.0.3
The backtrace doesn't see class b at all, all references to it have
vanished into thin air.
as a side note - using a function like debug_backtrace() seems to be a
mis-use -- the debug_ prefix is a pretty clear indication that this is
to retrieve info for helping you figure out what is wrong, and therefore
it probably not a good idea to write code that relies on its output in a
production env.
I spent days trying to solve this on my own until I happened upon this
thread - it appears that there is no clean way of retrieving the name
of the calling class, in a classmethod defined in the superclass. I do
not want to overload the sperclass' method.
that probably wouldn't solve the problem unless you duplicate the whole
function...
what about doing this in the superclass
yourFunc( $className = '' )
{
if (empty($className)) {
$className = __CLASS__;
}
return parent::yourFunc( $className );
}
I'll have to wait until I get to work tomorrow to check this one out.
But offhand I cannot see it working as I want it to. Sorry.
not perfect, but it would allow you to stack the classes and minimize
the code in the overloaded funcs. obviously the original func would use
the argument to determine which class it was called by. hopefully you
get the idea.
I do not accept that this is misusing the static concept - without it,
actually I agree - but then I'm no expert :-)
PHP 5 seems rather lame. How does one go about making a feature request?
calling PHP5 lame is a little harsh - one 'missing' feature is not the
end of the world - and there are work around.
I feel that this 'missing feature' is a sadly lacking implementation of
the concept and use of classmethods. The gurus/implementors might argue
otherwise, but I believe that being able to tell the class of the
originating call is a logical cause of the static (classmethod) concept
- without it the implementation of classmethods seems incomplete, and
hence lame. I probably should have made this clearer...
Also, I believe that any workaround here is highly undersirable. With
PHP5 we got a very decent object model which made it possible to model
and implement our solutions in a professional way. Overloading in
subclass only to get around a "silly" misimplemenation of classmethods
is the ghost of versions past...
I'm writing a framework that should do as much work as possible in the
superclass, leaving only tasks specific the the subclass to be
implemented in the subclass. Anything else is mickey mouse.
I bet you can feel the resentment :-)
feature requests are done via the bugs DB:
http://bugs.php.net/
Great! But Torsten already is on this mission, it seems.
take the time to thoroughly investigate the DB for similar requests
first though, to avoid duplication. Also you may want to politely
inquire at php-internals@xxxxxxxxxxxxx before you do so - possibly they
may have some clarification or could point you to earlier discussions
that explain the current developer stance.
There has to be a way to get this implemented into PHP 5...
well if you can write C then definitely - you write it, and submit a
patch - even if its not accepted you can roll your own version. :-)
I write C well, but I'd rather stick to a standard distro then my own
rolll. Besides, I just don't have the time to do this.
Cheers,
-Morten
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
