Martin Scotta
On Mon, May 16, 2011 at 4:10 PM, Anthony Ferrara wrote:
> Personally, I really don't care for something like this. Would it be
> caught by a __call declaration if one existed (since it is a call to
> an undefined method)? Would you expect it to?
>
Although current PHP implement
>From what I can tell, whatever changes made to fix this bug, are independent
of #54384.
Bug #54384 happens when the parent ctor is not called. This bug is triggered
only when it is called.
I did a quick check of the code and that seems to be the case.
But the existence of that bug makes me think
Hi folks,
On 16 May 2011 22:25, Etienne Kneuss wrote:
> Hi,
>
> On May 16 16:52:08, Andrew Curioso wrote:
>> Well, that wasn't where I was expecting that thread to go, but to wrap it up
>> what do you think...
>> Is it too late to put this on the 5.4 roadmap for consideration?
>>
>> I'm assuming
On Tue, May 17, 2011 at 4:22 AM, Benjamin Dubois
wrote:
> Why not make all objects (maybe implicitly) extend a single root object,
> containing just skeleton ctor/dtor and implemented in the engine ?
>
> I don't know if it is actually possible in PHP, but that works for several
> other languag
Am 17.05.2011 um 02:22 schrieb Benjamin Dubois :
> Hi,
>
> Why not make all objects (maybe implicitly) extend a single root object,
> containing just skeleton ctor/dtor and implemented in the engine ?
>
> I don't know if it is actually possible in PHP, but that works for several
> other l
Hi,
Why not make all objects (maybe implicitly) extend a single root object,
containing just skeleton ctor/dtor and implemented in the engine ?
I don't know if it is actually possible in PHP, but that works for several
other languages (java, objC - in that case, the root object is explicit-, C
I had given up on someone actually going with one of my original ideas for
fixing the bug!
That is where I was leaning but I would take it a step further and add
constructors to all SPL classes even if the docs don't currently list one.
In regards to the implicit ctor and dtor. I don't thing it is
Hi,
On May 16 16:52:08, Andrew Curioso wrote:
> Well, that wasn't where I was expecting that thread to go, but to wrap it up
> what do you think...
> Is it too late to put this on the 5.4 roadmap for consideration?
>
> I'm assuming just the implicit ctor and dtor. Not all magic methods (not
> now
Well, that wasn't where I was expecting that thread to go, but to wrap it up
what do you think...
Is it too late to put this on the 5.4 roadmap for consideration?
I'm assuming just the implicit ctor and dtor. Not all magic methods (not
now, at least).
With your OK, Stas, I'd like to write up an R
Hi!
Well, if we follow that logic (which does make sense), then shouldn't
all magic methods be implicit? So parent::__sleep/__call/__get/etc
would silently do the default if not defined?
In most cases, you are required to call parent ctor, but there's no such
requirement for other methods. C
That is a whole other can of worms. Whereas __construct() and __destruct()
can do nothing and are probably pretty trivial to get working, some other
methods aren't so clear cut.
Example: __sleep() would have to return an array of member variables so
that it does what is expected when called by the
> No and no. __call is not called for ctors, for obvious reasons (__call is an
> object method, and before ctor is done the object is not ready). It was
> always this way.
It is called from constructors, just not *for* constructors:
class test {
public static function __callStatic($name, $arg
Well, if we follow that logic (which does make sense), then shouldn't
all magic methods be implicit? So parent::__sleep/__call/__get/etc
would silently do the default if not defined?
On Mon, May 16, 2011 at 3:18 PM, Andrew Curioso wrote:
> To play devil's advocate a bit:
>
> It's a special case.
Hi!
Personally, I really don't care for something like this. Would it be
caught by a __call declaration if one existed (since it is a call to
an undefined method)? Would you expect it to?
No and no. __call is not called for ctors, for obvious reasons (__call
is an object method, and before
To play devil's advocate a bit:
It's a special case. If it was really an undefined method then this is
suddenly ambiguous:
$foo = new Foo();
If __construct() is undefined, what is being called in that case? By the
same logic, that should
throw an error as well.
On the other hand, if __construct
Personally, I really don't care for something like this. Would it be
caught by a __call declaration if one existed (since it is a call to
an undefined method)? Would you expect it to?
I'd rather see calls to non-existent methods generate a catachable
fatal error (rather than a hard fatal error t
I like that idea and I like that it works for userland classes as well.
+1
Do you think it should throw a warning, notice, or -- as you both suggested
-- just silently succeed?
2011/5/16 Johannes Schlüter
> Hi,
>
> I|d actuallz suggest a different option:
>
> If a parent constructor is call
Hi,
I|d actuallz suggest a different option:
If a parent constructor is called but doesn't exist the engine should
ignore this. The same goes for destructors.
This solution would also work for userland classes.
johannes
On Mon, 2011-05-16 at 14:14 -0400, Andrew Curioso wrote:
> So, I ran acros
Hi!
A fatal error is thrown if you try to call parent::__construct() from a
subclass
of SplObjectStorage.
I'm thinking maybe it'll be useful to make parent::__construct silently
succeed if parent class exists but has no ctor.
The reason for that that for many classes you _have_ to call pare
So, I ran across bug #54631
A fatal error is thrown if you try to call parent::__construct() from a
subclass
of SplObjectStorage.
I was going to close it as "expected behavior" since that is pretty normal
if the parent class doesn't implement __construct().
Also, the docs don't list it as having
20 matches
Mail list logo
