== 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.
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 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"
>
== 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 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 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 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 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 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 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 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 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 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 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
> 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 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() {
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 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
== 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 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 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
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 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
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
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
>
== 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
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
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
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
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
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
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
32 matches
Mail list logo
