[PHP-DEV] Problems and questions with all the zend changes
I started running through dom and have now run into a lot of issues I need to get
resolved. Not sure if they are problems with the extension or engine bugs. Here is
what I am running into.
Can no longer call static methods:
i.e. DomDocument:loadXML() - results in Non-static method error (this used to work)
Do the functions need to be registered now with the ACC flags?
If so, is there any way to do this without renaming all functions? As the
functions that take flags arguments all register classname_
When a static method is called in some objects constructor, The method is allowed to
be called (unlike above), though there is an id of std_class being passed in, so I
take it must be checked with instanceof() in order for a method to be able to be
called as an object method as well as a static method.
Regarding the above, however, testing this with simplexml, which has the flags set for
the functions, the function is still allowed to be called statically:
class Test
{
function __construct()
{
print simplexml_element::asXML(); // crashes as simpleXML is not expecting this is
valid.
}
}
$a = new Test();
function asXML is defined:
Re: [PHP-DEV] Problems and questions with all the zend changes
Damn it went before I finished :(
class Test
{
function __construct()
{
print simplexml_element::asXML(); // crashes as simpleXML is not expecting this is
valid.
}
}
$a = new Test();
As I was saying:
function asXML is defined as:
SXE_ME(asXML, NULL, ZEND_ACC_PUBLIC)
so it shouldnt be able to be called statically, though in a class constructor it is
able to be called.
My questions boil down to which are problems with the extensions and which are bugs in
the engine?
[PHP-DEV] Bug in SimpleXML
Hey, When you do something like: print $sxe->name->asXML(); asXML() prints the XML for the whole object and not for the node. I think it's a bug. Can one of the SimpleXML maintainers please take a look at this? Thanks, Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: Re: dl() problem
At 22:50 12/02/2004, Andrei Zmievski wrote: On Wed, 11 Feb 2004, Zeev Suraski wrote: > By the way - dl() is trivial to implement if we were to go down your path, > and make dl()'s persist forever. However, that's exactly where the problem > is coming from - it completely doesn't fit the theme of PHP (not to mention > the security and resource usage concerns, which are completely valid, but > secondary). I'm just curious, what is PHP's theme, in this case? Isolation of requests. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Improving error messages when using indirect references
Hey, results in Notice: Undefined variable: foo in /foo/bar.php on line 4 Notice: Undefined variable: in /foo/bar.php on line 4 Wouldn't it be more appropriate if the second notice was something like "Notice: Undefined variable: in /foo/bar.php on line 4"? -- - Martin Martin Jansen http://martinjansen.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improving error messages when using indirect references
Martin Jansen wrote: Hey, echo $$foo; ?> results in Notice: Undefined variable: foo in /foo/bar.php on line 4 Notice: Undefined variable: in /foo/bar.php on line 4 Wouldn't it be more appropriate if the second notice was something like "Notice: Undefined variable: in /foo/bar.php on line 4"? i'd prefere to put the variable name in single quotes here as the name actually is '' (empty string) -- Hartmut Holzgraefe <[EMAIL PROTECTED]> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improving error messages when using indirect references
On Fri, 13 Feb 2004, Martin Jansen wrote: > Hey, > > error_reporting(E_ALL); > > echo $$foo; > ?> > > results in > > Notice: Undefined variable: foo in /foo/bar.php on line 4 > > Notice: Undefined variable: in /foo/bar.php on line 4 > > Wouldn't it be more appropriate if the second notice was something like > "Notice: Undefined variable: in /foo/bar.php on line 4"? Would be a lie... $foo WILL evaluate to the empty string which used like this, although it does look weird, it is right :) Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug in SimpleXML
From: Andi Gutmans > When you do something like: > print $sxe->name->asXML(); > > asXML() prints the XML for the whole object and not for the node. > I think it's a bug. Can one of the SimpleXML maintainers please take a look > at this? Fixed. Thanks, Rob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: ckh0618
translating Smarty! document to Korean. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_default_classes.c zend_default_classes.h zend_execute.h zend_execute_API.c
On Feb 13, 2004, at 11:35 AM, Adam Maccabee Trachtenberg wrote: Andi's point, I believe, is that otherwise we'll need to add a "finally" keyword to make sure some random extension doesn't throw some random undocumented exception that you could miss. And I agree with him. It just seems to make everything more clean. And my point is that I may want to create an exception (sterling's 'InternalException', for example), that I do not want you catching unless you specifically check for it. Moving this discussion to [EMAIL PROTECTED] George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Loading Custom Extensions in PHP 4.3.1
Hi What are the functional or practical differences between loading a custom extension via 'extension=' in the php.ini file and having the extension automatically load by building php using --enable? I have an extension that calls libraries written in C++ and I see sporadic core dumps when loading the extension via the php.ini entry. Thanks, Bruce _ Plan your next US getaway to one of the super destinations here. http://special.msn.com/local/hotdestinations.armx -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_default_classes.c zend_default_classes.h zend_execute.h zend_execute_API.c
George Schlossnagle wrote:
On Feb 13, 2004, at 11:35 AM, Adam Maccabee Trachtenberg wrote:
Andi's point, I believe, is that otherwise we'll need to add a
"finally" keyword to make sure some random extension doesn't throw
some random undocumented exception that you could miss. And I agree
with him. It just seems to make everything more clean.
'Finally' is used for code that is executed anyway, whether an exception
has occurred or not. This is different from 'catch (...)' because the
catch clause is not executed if the try block exits with no eceptions.
Like
try {
// open file
// do something that throws()
}
catch (Exception $e)
{
// do nothing
}
// close file
// re-throw
if ($e) throw $e;
'Finally' would be useful, but can be emulated as shown.
Personally, I like the compulsory derivation for 'throw' operands, but I
would prefer it to be an interface instead of a class. In that case, it
is a lot easier to plug your own class (hierarchy) into the exception
framework.
--
Ard
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_default_classes.c zend_default_classes.h zend_execute.h zend_execute_API.c
At 08:12 AM 2/13/2004 -0500, Sterling Hughes wrote:
> zeev Thu Feb 12 05:24:40 2004 EDT
>
> Modified files:
> /ZendEngine2 zend_default_classes.c zend_default_classes.h
> zend_execute.h zend_execute_API.c
> Log:
> Exceptions updates:
>
> - Enforce exceptions to be derived from class Exception. This allows
> users to perform catch-all. It's not yet complete, so don't get
> comfortable with it just yet :) Updates are coming soon.
This is imho wrong. Exception is not a requirement, but an optional
thing. For the most part, all user exceptions should inherit from
"Exception," but that same onus is not on extension space exceptions, or
exceptions that are meant to be thrown out of bounds.
Ie, you should be able to have:
try {
foo();
} catch (Exception $e) {
} catch (InternalException $ie) {
}
What is the reasoning for this new change?
The reasoning is that it allows users to do a catch-all (which otherwise
we'd add to the language syntax). It also adds cleanliness to the Exception
hierarchy and allows PHP code to interact with PHP code which isn't written
by the developer knowing that there's a common interface (such as
getMessage()) which the exception always adheres to. That improves the
ability of exception handling especially debugging and logging significantly.
i.e.
try {
...// Main code which calls PEAR, SOAP, Smart, external stuff and
so on
} catch (Exception $e) {
print "Damn something is really wrong here\n";
print $e->getMessage();
}
Andi
--
Zend Engine CVS Mailing List (http://cvs.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_default_classes.c zend_default_classes.h zend_execute.h zend_execute_API.c
At 08:51 AM 2/13/2004 -0500, George Schlossnagle wrote: On Feb 13, 2004, at 8:39 AM, Andi Gutmans wrote: At 08:12 AM 2/13/2004 -0500, Sterling Hughes wrote: What is the reasoning for this new change? The reasoning is that it allows users to do a catch-all (which otherwise we'd add to the language syntax). It also adds cleanliness to the Exception hierarchy and allows PHP code to interact with PHP code which isn't written by the developer knowing that there's a common interface (such as getMessage()) which the exception always adheres to. That improves the ability of exception handling especially debugging and logging significantly. The above description sounds more like a 'best practice' and less like something that PHP should be forcing on users. If I explicitly choose to create an exception that must be caught specifically, I don't see why I shouldn't be allowed to do that. Because, in any case, we would then add a construct to catch all exceptions but you'd loose out on the fact that you don't have an interface you can rely on. At the end of the day, if you look at the two alternatives, I think this is the best one and leads to much better and robust code. Andi -- Zend Engine CVS Mailing List (http://cvs.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_default_classes.c zend_default_classes.h zend_execute.h zend_execute_API.c
> > On Feb 13, 2004, at 11:35 AM, Adam Maccabee Trachtenberg wrote: > >Andi's point, I believe, is that otherwise we'll need to add a > >"finally" keyword to make sure some random extension doesn't throw > >some random undocumented exception that you could miss. And I agree > >with him. It just seems to make everything more clean. > > > And my point is that I may want to create an exception (sterling's > 'InternalException', for example), that I do not want you catching > unless you specifically check for it. > > Moving this discussion to [EMAIL PROTECTED] > Right. Exception heirarchies are nice and all, but sometimes you want exceptions to leak through, or be explicitly caught. In-fact, I've never encountered a case where this isn't what I want, maybe in a small 20 line example, but in large scripts I've almost always designed for leakage. I contend that what you want in this case is a Throwable interface or none at all. Java provides just this differentiation btw. -Sterling -- "Reductionists like to take things apart. The rest of us are just trying to get it together." - Larry Wall, Programming Perl, 3rd Edition -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_default_classes.c zend_default_classes.h zend_execute.h zend_execute_API.c
>
> The reasoning is that it allows users to do a catch-all (which otherwise
> we'd add to the language syntax). It also adds cleanliness to the Exception
> hierarchy and allows PHP code to interact with PHP code which isn't written
> by the developer knowing that there's a common interface (such as
> getMessage()) which the exception always adheres to. That improves the
> ability of exception handling especially debugging and logging
> significantly.
>
That second part is a Throwable interface, not a base class (and
Exception isn't even an ABC.)
> i.e.
>
> try {
> ...// Main code which calls PEAR, SOAP, Smart, external stuff and
> so on
> } catch (Exception $e) {
> print "Damn something is really wrong here\n";
> print $e->getMessage();
> }
>
I get the concept, that's the reason Exception was added. But its meant
to be a voluntary thing (I believe this has been discussed before btw),
a standard class that gives users something to build upon, should they
want to. I think an all-your-base-is-belonging-to-Exception is the
wrong way to go. If you really want a catch-all or some type of
consistency the way to go is either a Throwable interface (which makes
it more of a pain to write exceptions) or the generic:
catch ($e) {
}
syntax.
_Sterling
--
"Reductionists like to take things apart. The rest of us are
just trying to get it together."
- Larry Wall, Programming Perl, 3rd Edition
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_default_classes.c zend_default_classes.h zend_execute.h zend_execute_API.c
On Fri, 13 Feb 2004, Sterling Hughes wrote: > > And my point is that I may want to create an exception (sterling's > > 'InternalException', for example), that I do not want you catching > > unless you specifically check for it. > > Right. Exception heirarchies are nice and all, but sometimes you want > exceptions to leak through, or be explicitly caught. In-fact, I've > never encountered a case where this isn't what I want, maybe in a small > 20 line example, but in large scripts I've almost always designed for > leakage. Yeah, i agree with this. From what I understood is that Sterling's new addition was only there for the lazy people not wanting to implement the few standard methods. I also see a reason why to allow leaking exceptions. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
