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
2011/5/16 Michael Morris :
> Question from the peanut gallery. Is the removal of magic_quotes and
> register_globals going to be done on this release, or is that still being
> put off for PHP 6?
>
So far all the legacy features have been removed from 5.4, except
magic_quotes which still is pe
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
Question from the peanut gallery. Is the removal of magic_quotes and
register_globals going to be done on this release, or is that still being
put off for PHP 6?
On 05/16/2011 01:39 PM, Jeraimee Hughes wrote:
This time, the correct patches and a new gist url:
https://gist.github.com/975322
Again, no karma to commit them. Sorry about the bad gist.
What makes you think you have no karma? You should have access to commit
to */tests and phpdoc. Could you
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
This time, the correct patches and a new gist url:
https://gist.github.com/975322
Again, no karma to commit them. Sorry about the bad gist.
- Jeraimee
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
On 16.05.2011 14:15, Felipe Pena wrote:
> Other examples and patch at:
> https://wiki.php.net/rfc/improved-parser-error-message
Just for completeness, here's the lengthy thread
we had in October 2010 about this:
http://news.php.net/php.internals/49978
FWIW, I like the Easter Egg :)
Greetings,
F
No karma to commit these patches so here's the gist of the fixes I did the
other day:
https://gist.github.com/974926
- Jeraimee
Am 16.05.2011 15:50, schrieb Alain Williams:
> On Mon, May 16, 2011 at 03:41:29PM +0200, Reindl Harald wrote:
>> There is no function needed if you use
>> http://php.net/manual/de/function.session-write-close.php
>> like others do since ten years :-)
>
> But that writes $_SESSION back. I am loo
+1
Regards
Pierrick
On 16 May 2011 08:15, Felipe Pena wrote:
> Hi all,
> As I have proposed previously in an old thread... What about we name all
> the
> tokens to have an improved parser error message? (i.e. anymore
> T_PAAMAYIM_NEKUDOTAYIM, T_DOLLAR_OPEN_CURLY_BRACES in the messages etc)
>
>
Hi Felipe,
On May 16 9:15:24, Felipe Pena wrote:
> Hi all,
> As I have proposed previously in an old thread... What about we name all the
> tokens to have an improved parser error message? (i.e. anymore
> T_PAAMAYIM_NEKUDOTAYIM, T_DOLLAR_OPEN_CURLY_BRACES in the messages etc)
>
> Some examples:
It seems Rasmus already patched some date tests here:
http://svn.php.net/viewvc?view=revision&revision=311014
And my second patch (in previous letter) about bug 51819 is wrong,
will try to investigate it further.
More test fixes:
/trunk/ext/curl/tests/curl_setopt_basic001.phpt should probably be
On Mon, May 16, 2011 at 3:41 PM, Reindl Harald wrote:
> There is no function needed if you use
> http://php.net/manual/de/function.session-write-close.php
> like others do since ten years :-)
>
> if you know that you no longer write to the session use it
> this does not mean $_SESSION is lost
> it
On Mon, May 16, 2011 at 03:41:29PM +0200, Reindl Harald wrote:
> There is no function needed if you use
> http://php.net/manual/de/function.session-write-close.php
> like others do since ten years :-)
But that writes $_SESSION back. I am looking to optimise the case when you know
that there will
There is no function needed if you use
http://php.net/manual/de/function.session-write-close.php
like others do since ten years :-)
if you know that you no longer write to the session use it
this does not mean $_SESSION is lost
it means only that changes to $_SESSIOn are not available for other r
I am working on some AJAX callbacks. These need to open the session, get hold
of stuff in $_SESSION
and that is it ... they won't be changing the session data. The trouble is that
because the
session file is locked the Asynchronicity of AJAX is reduced a bit, especially
if some of the
server sid
Hi,
2011/5/16 Ferenc Kovacs
>
> +1
>
> do you think that this could cause some kind of BC?
> I don't think that anybody out there parses the tokens as is, but there are
> crazy people. :)
> the other thing that I can imagine that the developers will be surprised
> that they are getting meaningfu
On Mon, May 16, 2011 at 2:15 PM, Felipe Pena wrote:
> Hi all,
> As I have proposed previously in an old thread... What about we name all
> the
> tokens to have an improved parser error message? (i.e. anymore
> T_PAAMAYIM_NEKUDOTAYIM, T_DOLLAR_OPEN_CURLY_BRACES in the messages etc)
>
> Some exampl
Hi all,
As I have proposed previously in an old thread... What about we name all the
tokens to have an improved parser error message? (i.e. anymore
T_PAAMAYIM_NEKUDOTAYIM, T_DOLLAR_OPEN_CURLY_BRACES in the messages etc)
Some examples:
$ sapi/cli/php -r 'function ""'
Patched:
Parse error: syntax e
On Mon, May 16, 2011 at 11:42 AM, Richard Quadling wrote:
> "some devs simply do not want that"
>
> Why not?
You are asking the wrong person, I'm, for one, want a warning free
php, or almost free of warnings.
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Int
On 16 May 2011 00:44, Pierre Joye wrote:
> hi,
>
> On Mon, May 16, 2011 at 12:11 AM, Richard Quadling
> wrote:
>> On 15 May 2011 21:37, wrote:
>>>
>>> This is an automatic mail from the rmtoool's build bots.
>>>
>>> New build errors have been introduced between
>>> and 311062.
>>>
>>> The erro
36 matches
Mail list logo
