Hi,
I also find this syntax confusing and I think it has a huge WTF factor.
Some thoughts about the syntax:
- At the first glance, it isn't clear which visibility the getter or
setter has
- The extra indentation level makes the code more unreadable
class Foo {
/**
*
*/
priv
Hi:
I update the patch, instead of change the behavior of zbacktrace,
I add a new one "zbacktrace_ex",
I am going to commit it, if there comes some problems, then we
could revert or edit it.
thanks
On Tue, Dec 6, 2011 at 2:33 PM, Laruence wrote:
> Hi:
> I am plan to commit a new chan
Laruence, I think that there is no point opening a thread if you will go
ahead and commit after waiting 3 hours and 0 replies.
Or did I miss someting here?
On Tue, Dec 6, 2011 at 10:51 AM, Laruence wrote:
> Hi:
> I update the patch, instead of change the behavior of zbacktrace,
> I add a new
Hi:
I am not sure whether is okey to change the existing zbacktrace,
so I open a thread that let people know.
after that I change the patch, add a new zbacktrace_ex. I think
this should be okey, so I commit it. :)
sorry & thanks
On Tue, Dec 6, 2011 at 5:53 PM, Ferenc Kovacs wrote:
On 12/06/2011 10:33 AM, Laruence wrote:
Hi:
I am plan to commit a new change to 5.4-trunk/.gdbinit which can be
found at http://pastebin.com/N6hTRMRA.
Looks nice, please commit it.
--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime profiling for PHP
--
PHP Internals - PHP Runtime Devel
On Tue, 2011-12-06 at 17:59 +0800, Laruence wrote:
> Hi:
> I am not sure whether is okey to change the existing zbacktrace,
> so I open a thread that let people know.
>
> after that I change the patch, add a new zbacktrace_ex. I think
> this should be okey, so I commit it. :)
I don't
hi!
Good idea and very handy.
Btw, please add the bug # in the commit msg next time :)
Thanks!
On Tue, Dec 6, 2011 at 7:33 AM, Laruence wrote:
> Hi:
> I am plan to commit a new change to 5.4-trunk/.gdbinit which can be
> found at http://pastebin.com/N6hTRMRA.
>
> after update, the zbacktr
On Tue, Dec 6, 2011 at 4:23 AM, Clint M Priest wrote:
> I believe the attempt with the RFC was to mimic the syntax that C# went with,
> the RFC is here: https://wiki.php.net/rfc/propertygetsetsyntax
C# like setter/getter is definitely what I would like to have in PHP,
it is a very clear and know
Hi:
okey, if there is no objection, I will update the zbacktrace. :)
thanks
2011/12/6 Johannes Schlüter :
> On Tue, 2011-12-06 at 17:59 +0800, Laruence wrote:
>> Hi:
>> I am not sure whether is okey to change the existing zbacktrace,
>> so I open a thread that let people know.
>>
>>
Over the weekend I went ahead and created a patch to implement support
for SPKAC keys for the old/new KEYGEN element within the HTML5 spec.
According to feature requests at bugs.php.net I came accross this
existing request: https://bugs.php.net/bug.php?id=38917
I have filed a patch under this feat
Greetings PHP Intern@ls :)
There is a PHP behavior I disagree with regarding OO model.
It's been here for a long time (5.0 ??, at least 5.2, 5.3 and 5.4) , here
it is :
Strict Standards: Declaration of Foo2::bar() should be compatible with that
of Foo::bar()
I find this wrong.
Liskov (and the
On Tue, Dec 6, 2011 at 3:45 AM, Christian Kaps wrote:
> Hi,
>
> I also find this syntax confusing and I think it has a huge WTF factor.
>
> Some thoughts about the syntax:
> - At the first glance, it isn't clear which visibility the getter or
> setter has
> - The extra indentation level makes the
Hi,
On Tue, Dec 6, 2011 at 14:54, jpauli wrote:
> Greetings PHP Intern@ls :)
>
> There is a PHP behavior I disagree with regarding OO model.
> It's been here for a long time (5.0 ??, at least 5.2, 5.3 and 5.4) , here
> it is :
>
> interface Iface1 { }
> interface Iface2 extends Iface1 { }
>
> c
I prefer C# syntax myself but thinking about it, supporting both syntax's would
be fairly trivial to add... Thoughts on that?
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Tuesday, December 06, 2011 5:47 AM
To: Clint M Priest
Cc: Rasmus Schultz; internals@lists
Hi
2011/12/6 Rasmus Schultz
> On Tue, Dec 6, 2011 at 3:45 AM, Christian Kaps >wrote:
>
> > Hi,
> >
> > I also find this syntax confusing and I think it has a huge WTF factor.
> >
> > Some thoughts about the syntax:
> > - At the first glance, it isn't clear which visibility the getter or
> > set
On Dec 6, 2011, at 8:58 AM, Rasmus Schultz wrote:
> On Tue, Dec 6, 2011 at 3:45 AM, Christian Kaps
> wrote:
>
>> Hi,
>>
>> I also find this syntax confusing and I think it has a huge WTF factor.
>>
>> Some thoughts about the syntax:
>> - At the first glance, it isn't clear which visibility th
Hi:
I'm getting the following error while building trunk:
/php/php-src/trunk/ext/curl/interface.c: In function
‘zif_curl_copy_handle’:
/php/php-src/trunk/ext/curl/interface.c:1978: error: ‘php_curl_handlers’
has no member named ‘fnmatch’
/php/php-src/trunk/ext/curl/interface.c:1979: error: ‘php_c
Hi Again:
After sending that email, I realized I should mention my library
version. curl --version says, in part "7.19.7 (x86_64-pc-linux-gnu)".
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
I'll have a look just after my meeting. Thanks
Envoyé de mon iPhone / Sent from my iPhone
Le 2011-12-06 à 10:00, Daniel Convissor a
écrit :
> Hi Again:
>
> After sending that email, I realized I should mention my library
> version. curl --version says, in part "7.19.7 (x86_64-pc-linux-gnu)"
hi Pierrick,
CURLOPT_FNMATCH_DATA is 7.21.0 and later only. That's the cause of
this build error.
Btw, check out:
http://curl.haxx.se/libcurl/c/symbols-in-versions.html
Very handy to quickly check which features are available in which version :)
Cheers,
On Tue, Dec 6, 2011 at 4:03 PM, Pierrick
and fixed in svn, thanks for the headup!
On Tue, Dec 6, 2011 at 4:32 PM, Pierre Joye wrote:
> hi Pierrick,
>
> CURLOPT_FNMATCH_DATA is 7.21.0 and later only. That's the cause of
> this build error.
>
> Btw, check out:
>
> http://curl.haxx.se/libcurl/c/symbols-in-versions.html
>
> Very handy to qu
Hi Pierre:
Thanks for the quick fix. I did a make clean and vsclean then rebuilt,
but there's a similar issue, still:
/php/php-src/trunk/ext/curl/interface.c: In function
‘zif_curl_copy_handle’:
/php/php-src/trunk/ext/curl/interface.c:1978: error: ‘php_curl_handlers’
has no member named ‘fnmatch
Thanks Daniel for testing and Pierre for the fix :)
On 6 December 2011 10:53, Daniel Convissor wrote:
> Hi Pierre:
>
> Thanks for the quick fix. I did a make clean and vsclean then rebuilt,
> but there's a similar issue, still:
>
> /php/php-src/trunk/ext/curl/interface.c: In function
> ‘zif_cur
Hi Alan:
> b) fix isset, and return first character
> ISSET: return false (no warning)
> READ: warning + return first character (similar to current behavior
> except dereferenced strings)
>
> c) fix isset, and return empty strings
> ISSET: return false (no warning)
> READ: warning + return empty
Hi,
I don't want anyone to take it personal... But what is the status about
missing ob_gzhandler function (but also ob_tidyhandler and
ob_iconv_handler) ?
I put mike's patch and a comment to help track the BC break /potential
inconsistency :
https://bugs.php.net/bug.php?id=60326
Regards
Nicolas
Hi!
I don't want anyone to take it personal... But what is the status about
missing ob_gzhandler function (but also ob_tidyhandler and
ob_iconv_handler) ?
I put mike's patch and a comment to help track the BC break /potential
inconsistency :
https://bugs.php.net/bug.php?id=60326
Ah, I didn't
I need to check b) will work with dereferencing and isset - but yes, I think it
will probably be the best way to go for now.
the NOTICE is probably just a missing 'E_' so it should be E_NOTICE - I had a
typo there at one point.
Regards
Alan
--- On 07/Dec/2011, Daniel Convissor wrote:
> Hi Al
Hi!
I believe the attempt with the RFC was to mimic the syntax that C#
went with, the RFC is here:
https://wiki.php.net/rfc/propertygetsetsyntax
Reading this RFC I notice it makes get/set keywords. This would lead to
huge amount of breakage in existing code, so I strongly suggest to look
for a
The implementation specifically didn't introduce T_GET/T_SET on the
lexer side and instead checks for T_STRINGs with content "get" or
"set".
Nikita
On Wed, Dec 7, 2011 at 3:29 AM, Stas Malyshev wrote:
> Hi!
>
>
>> I believe the attempt with the RFC was to mimic the syntax that C#
>> went with, t
Can somebody look into https://bugs.php.net/bug.php?id=54514 please?
This causes issues for CLI tools implemented in PHP that are invoked
through Apache Ant, for instance, and need to know the PHP interpreter
that is running them.
See https://github.com/sebastianbergmann/phpunit/issues/432 f
30 matches
Mail list logo
