I'm currently using PHP4 and I'm evaluating PHP5 for its new exciting features.
I have some remarks, split into distinct posts.
The first one is about the current implementation of __clone():
* a derived __clone() can't call parent::__clone() because $that is only declared for
the first __clone
The current implementation of class Exception has a private "trace" member, which is
used to store the backtrace. But if you throw an exception of a derived class of
Exception, print_r() displays an empty "trace:private" member, as well as a "trace"
(public) member that really holds the backtrac
PHP implements an "stdClass". I expected that:
* this was the base class for all classes, even if they do not explicitly "extends
stdClass",
* this class implemented all the "standard" methods (__construct(), __destruct(), ...).
In the PHP5 presentation, it is mentionned the interest of unified c
Hello Marcus,
Hum... you fixed the issue but not really in the way I expected it. Now my code does
not work...
My message was not only to report a bug, but to ask *not* to fix it as expected.
Particularly to put the "trace" member as protected, (or "getTrace()" as virtual and
not final).
Reme
Marcus,
The idea behind this kind of request is to speed up development time. And the way a
language and its base classes are implemented could really help to reach this goal.
When you write "a change is a change", you're right. But the way you have written your
code could really reduce the ris
Marcus,
> you're right $that must be available in the derived __clone().
You will solve one problem: being able to call parent::__clone(), but it won't remove
the constraint on derived classes (declaring members) to implement __clone() when one
of its parents implements it.
This is just to limi
== Quote from Timm Friebe ([EMAIL PROTECTED])'s article
> It's basically the same with the built-in exception class. I can't have
> my own (at least not with the sexy-most name "Exception"). Then, in my
> (very personal) view I want it designed differently, and want to have it
> extend _my_ base cl
Hello Marcus,
== Quote from Marcus Boerger ([EMAIL PROTECTED])'s article
> i had reasons to make that property private. You may use getTrace() to
> read the contents and if you must overwrite it because you want to misuse
> the whole thing then you can overwrite the read access method, too. This
>
Chris,
For sure I can't answer to your question, but why would you only implement it to
construtors?
My original request was that all classes inherit from a base class provided by PHP
(even if not explicitly written), and that this base class implements all magic
methods in the appropriate way
== Quote from Christian Schneider ([EMAIL PROTECTED])'s article
> IMHO PHP doesn't need to be perfect in an academic OO sense but needs to
> provide what the majority of users need.
Yes, I'm certainly too much "academic" OO oriented, that's the reason why I think all
the magic methods must be im
Hello,
The following code does not work as expected:
foo;
print('[/test]'); // printed: bug
?>
'/get' is not printed, so the throw statement is correctly executed, but '/test' is
printed, so the exception is not correctly "propagated" to the caller.
Note that the exception will be thrown later
== Quote from Zeev Suraski ([EMAIL PROTECTED])'s article
> Andi and I have revisited the __clone() implementation and must agree that
> it wasn't quite right (mainly due to it not working with inheritance).
> We have rewritten it now (major change!!!) because we didn't want PHP 5 to
> be released w
== Quote from Zeev Suraski ([EMAIL PROTECTED])'s article
> Both are valid points, and they both sound like the same problem from two
> different angles. I think that the best approach would be to first do an
> implicit clone (i.e., 'dumb' copy of all of the elements), and then call
> __clone(), ev
== Quote from Ferdinand Beyer ([EMAIL PROTECTED])'s article
> I like the new way very much but I dislike that PHP tells me how to
> name a function parameter. __set() and __get(), for instance, do not
> force fixed argument names either, do they?
I agree.
Anyway, do we now need $that to be passed
== Quote from Markus Fischer ([EMAIL PROTECTED])'s article
> At least, saying 'InstantiateMe->' looks wrong to me as I'm calling
> 'StaticClass::' actually.
You have to declare your method as static:
Stephane
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visi
The new implementation of exception mechanism solves the problem with __get and
__toString, but throwing an exception within __set results in a segmentation fault.
Stephane
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
== Quote from Red Wingate ([EMAIL PROTECTED])'s article
> Is the removal of a specific order on the __destruct() calls
> necessary? It's a pain in the ass the be unable to predict
> in which order the __destruct() calls are made.
I did the following test:
n = $n;
}
function __destruct() {
== Quote from Zeev Suraski ([EMAIL PROTECTED])'s article
> To make a long story short, no. Circular references are hardly the
> problem, even a one-sided reference can be problematic. Just one example
> (there are many others) - you have $container and $obj, both are global
> variables, $containe
== Quote from Zeev Suraski ([EMAIL PROTECTED])'s article
> If you're talking about destruction that honors reference counts (which has
> nothing to do with order, it's still randomly-ordered), then yes, it's
> *generally* ok.
Yes, I was talking about that point.
> But that what we had before, an
== Quote from Zeev Suraski ([EMAIL PROTECTED])'s article
> They're not locked to 1, and nothing in a symbol table will ever be with a
> refcount of less than 1... But generally, all global variables (or for
> that matter, all variables period) have a refcount of 1, unless you do
> something 'speci
== Quote from Andi Gutmans ([EMAIL PROTECTED])'s article
> He doesn't necessarily own a reference but tries to access it in the
> destructor.
IMO, this is bad programming. If an object wants to access another object (global or
not), it has to own a reference on it, to guaranty the referenced obje
== Quote from Stephane Drouard ([EMAIL PROTECTED])'s article
> == Quote from Andi Gutmans ([EMAIL PROTECTED])'s article
> > He doesn't necessarily own a reference but tries to access it in the
> > destructor.
>
> IMO, this is bad programming. If an object wants
== Quote from Eric Daspet ([EMAIL PROTECTED])'s article
> Be carreful, this does not resolve all things :
>
> $source1 = new stdClass ;
> $source2 = new stdClass ;
> $source3 = new stdClass ;
> $refLevel1 = new stdClass ;
> $refLevel2 = new stdClass ;
>
> $source1->ref = $refLevel1 ;
> $source2->re
== Quote from Andi Gutmans ([EMAIL PROTECTED])'s article
> I rolled a preliminary beta 4 package just to make sure nothing is
> seriously broken. You can still commit fixes in the next few hours and if I
> don't hear of any serious show stoppers, I'll re-bundle and release beta 4
> later today.
An
== Quote from Andi Gutmans ([EMAIL PROTECTED])'s article
> Marcus didn't mean it adds complexity to the code but to PHP. It's
> obviously quite easy to implement this interface; implementation was never
> a problem.
> I don't really care too much if we have such an interface or not, although
> I do
== Quote from Marcus Boerger ([EMAIL PROTECTED])'s article
> as i said before there is a reason for that: I played a long time with
> exceptions until they became what they are right now. And and attempt
> to increase the visibility of one of its members can be used to make it
> SEGV. So i don't wa
== Quote from Marcus Boerger ([EMAIL PROTECTED])'s article
> No those are read access members to private property members. When you lok
> at the exception class:
> php -r 'reflection_class::export("exception");'
> then you'll encounter that you can overload __toString() and the
> __construct(). O
== Quote from Derick Rethans ([EMAIL PROTECTED])'s article
> On Tue, 17 Feb 2004, Stanislav Malyshev wrote:
>
> > >> >Again, I don't see any complexity arising from this: The average user
> > >> >would simply use "catch (IException $e)" instead of "catch (Exception
> >
> > That looks weird. Why IEx
== Quote from Hans Lellelid ([EMAIL PROTECTED])'s article
> In more traditional PHP this works fine:
>
> class A {
> function init() { ... }
> function doSomething($arg1, $arg2) { ... }
> }
>
> class B extends A {
> function doSomething($arg1, $arg2, $arg3, $arg4 = null) { ... }
> f
== Quote from Greg Beaver ([EMAIL PROTECTED])'s article
> class foo {
> static function bar()
> {
> echo 'hello';
> }
> }
>
> $bar = 'hello';
> $a = new foo;
> $a->bar(); // this could be disabled to error out easily
> $a::bar(); // my patch now allows this to print "hello"
>
As this document refers to zend-engine-2.php, this latter should be updated. Here are
some remarks:
Private and Protected Members
* reverse $Bar and $Foo strings
* instead of "should/shouldn't print" -> OK or error
Interfaces
* may choose another name than the polemical "Throwable" one ;-)
C
== Quote from Andi Gutmans ([EMAIL PROTECTED])'s article
> a) Don't check signature for constructors.
Constructors are definitely not virtual methods. So no reason to check signature.
Moreover, this is a non sense to declare constructors in interfaces or abstract
constructors in abstract classes.
32 matches
Mail list logo
