Hi:
okey,
I have updated the vote wiki page.
thanks
2011/7/11 Stas Malyshev :
> Hi!
>
> On 7/9/11 6:47 AM, Laruence wrote:
>>
>> Hi:
>>
>> can we add "Foreach supporting T_LIST token" into this vote?
>>
>> RFC: https://wiki.php.net/rfc/foreachlist
>
> If the author thinks it's mature enough h
Hi Rasmus:
As an shot notation for
Foreach( $arr as $ var) {
List($foo , $bar) = $var;
}
I ageer you opinion that using list in Foreach make code hard to
rewrite . But this up to php developer? Isn't it?
We offer this feature as an optional short way
Hi,
Voting for the Object oriented session handlers RFC is now closed.
Results can be found here:
https://wiki.php.net/rfc/session-oo/vote
The RFC was accepted (22 for, 0 against.)
There's a minor change to the patch which I haven't got around to yet
(see Felipe's mail on the RFC thread) - I
Hello list,
I'd like to share a brief critique of the proposed "foreachlist" feature -
https://wiki.php.net/rfc/foreachlist
The argument that this makes code more flexible, is questionable - in my
opinion, it makes the code less flexible, since nested arrays have to be
nested with their dimensio
On Jul 10, 2011, at 4:46 PM, Stas Malyshev wrote:
> Hi!
>
> On 7/10/11 4:23 PM, Scott MacVicar wrote:
>> The code for this looks really convoluted, I'm thinking we should
>> back out this multicast option for now. It's basically not going to
>> work on OSX the way its implemented from what I can
Hi!
On 7/10/11 4:07 PM, Felipe Pena wrote:
To handle the class name in a method call turn out tricky. For example:
include::list();
Agreed, class names would be trouble. Same with any token that can be
first in the expression/statement. However, I think methods might be
relatively safe, if
Hi!
On 7/10/11 4:23 PM, Scott MacVicar wrote:
The code for this looks really convoluted, I'm thinking we should
back out this multicast option for now. It's basically not going to
work on OSX the way its implemented from what I can tell.
I don't know much about this code (or multicast in gener
Em 10 de julho de 2011 20:21, Stas Malyshev escreveu:
> Hi!
>
> I was now building 5.4 on Mac with sockets enabled and got this:
>
> /Users/smalyshev/php-5.4/ext/sockets/multicast.c: In function
> ‘php_if_index_to_addr4’:
> /Users/smalyshev/php-5.4/ext/sockets/multicast.c:426: error: ‘struct ifreq
On Jul 10, 2011, at 4:21 PM, Stas Malyshev wrote:
> Hi!
>
> I was now building 5.4 on Mac with sockets enabled and got this:
>
> /Users/smalyshev/php-5.4/ext/sockets/multicast.c: In function
> ‘php_if_index_to_addr4’:
> /Users/smalyshev/php-5.4/ext/sockets/multicast.c:426: error: ‘struct ifreq’
Hi!
I was now building 5.4 on Mac with sockets enabled and got this:
/Users/smalyshev/php-5.4/ext/sockets/multicast.c: In function
‘php_if_index_to_addr4’:
/Users/smalyshev/php-5.4/ext/sockets/multicast.c:426: error: ‘struct
ifreq’ has no member named ‘ifr_ifindex’
/Users/smalyshev/php-5.4/ext
Hi,
2011/7/10 Lars Strojny :
> Hi Felipe,
>
> Am 11.07.11 00:41 schrieb "Felipe Pena" unter :
>
>>I'm against this patch, because we will just add more inconsistency.
>>Allow reserved words in method name, OK. But what about class
>>name/namespace name etc?
>
> Good argument, namespace names and c
Hi Felipe,
Am 11.07.11 00:41 schrieb "Felipe Pena" unter :
>I'm against this patch, because we will just add more inconsistency.
>Allow reserved words in method name, OK. But what about class
>name/namespace name etc?
Good argument, namespace names and class names should be treated similar.
Woul
2011/7/10 Lars Strojny :
> Hi everybody,
>
> Attached is the patch against current trunk with a testcase, tokenizer
> tests do not break. If nobody objects, could somebody with commit access
> to Zend could commit this patch?
>
Wait, wait.
Tokenizer surely is broken, it will identify a method nam
Hi,
2011/7/10 Nikita Popov :
> On Sun, Jul 10, 2011 at 11:37 PM, Lars Strojny wrote:
>>
>> Very good find of an inconsistency. Does the testsuite reveal something
>> strange with that patch?
>
>
> I didn't test that patch, just found it in the bugtracker.
> cel...@php.net would be a better person
And again, as .txt
Am 11.07.11 00:36 schrieb "Lars Strojny" unter :
>Hi everybody,
>
>Attached is the patch against current trunk with a testcase, tokenizer
>tests do not break. If nobody objects, could somebody with commit access
>to Zend could commit this patch?
>
>With regards,
>Lars
>
>Am 10.
Hi everybody,
Attached is the patch against current trunk with a testcase, tokenizer
tests do not break. If nobody objects, could somebody with commit access
to Zend could commit this patch?
With regards,
Lars
Am 10.07.11 23:51 schrieb "Nikita Popov" unter :
>On Sun, Jul 10, 2011 at 11:37 PM, L
On Sun, Jul 10, 2011 at 11:37 PM, Lars Strojny wrote:
>
> Very good find of an inconsistency. Does the testsuite reveal something
> strange with that patch?
I didn't test that patch, just found it in the bugtracker.
cel...@php.net would be a better person to ask, as he wrote it. But
just from gl
ZF and ODM do it and inside namespace. We should be sure that these
cases still work, as NS exists for this exact purpose.
Cheers,
On Sun, Jul 10, 2011 at 11:24 PM, Ferenc Kovacs wrote:
> On Sun, Jul 10, 2011 at 11:17 PM, Pierre Joye wrote:
>> hi,
>>
>> As I could agree on this fact, I can't fi
Very good find of an inconsistency. Does the testsuite reveal something
strange with that patch?
Am 10.07.11 19:41 schrieb "Nikita Popov" unter :
>Well, I generally think that PHP should be less strict about reserved
>keywords. The number
>of reserved keywords increases with every further release
On Sun, Jul 10, 2011 at 11:17 PM, Pierre Joye wrote:
> hi,
>
> As I could agree on this fact, I can't find any existing project
> having int(eger), float&co as class, namespaced or not. Do you have
> any example at hand?
>
> Cheers,
>
https://github.com/search?type=Code&language=PHP&q=%22class+in
hi,
As I could agree on this fact, I can't find any existing project
having int(eger), float&co as class, namespaced or not. Do you have
any example at hand?
Cheers,
On Sun, Jul 10, 2011 at 6:41 PM, Patrick ALLAERT wrote:
> 2011/6/17 Stas Malyshev :
>
> [snip]
>
>> 2. Make primitive type names
hi,
As I would love to kill ext/mysql, it is up to the mysql developers to decide.
Cheers,
On Sun, Jul 10, 2011 at 7:03 PM, Philip Olson wrote:
> Greetings PHP geeks,
>
> Don't panic! This is not a proposal to add errors or remove this popular
> extension. Not yet anyway, because it's too popu
On July-10-11 1:16 PM Reindl Harald wrote:
> Am 10.07.2011 19:03, schrieb Philip Olson:
> > What this means to ext/mysql:
> >
> > - Softly deprecate ext/mysql with education (docs) starting today
> > - Not adding E_DEPRECATED errors in 5.4, but revisit for 5.5/6.0
> > - Add pdo_mysql examples withi
Hi!
On 7/10/11 12:02 PM, Johannes Schlüter wrote:
I can call it in some way. It won't ensure that the signature is
compatible with what I expect.
Well, it's like array type - you know it's an array but you can't know
if it contains certain element that you expect, for example. As I'm not
a b
Hi!
On 7/10/11 10:41 AM, Nikita Popov wrote:
I don't know whether this is actually possible, but I've at least
already seen a patch
(http://pear.php.net/~greg/smarter_lexer.patch.txt) for the methodname
case linked
from a feature request (https://bugs.php.net/bug.php?id=28261).
If this patch i
Hi!
On 7/10/11 9:41 AM, Patrick ALLAERT wrote:
I'm sure some projects have defined classes with those keywords in
some namespace (to ensure they wouldn't conflict with possible PHP
built-in stuff) like in:
namespace \Types {
class Int {
// ...
}
class Float {
//
Hi!
On 7/9/11 6:47 AM, Laruence wrote:
Hi:
can we add "Foreach supporting T_LIST token" into this vote?
RFC: https://wiki.php.net/rfc/foreachlist
If the author thinks it's mature enough he can put it up to the vote.
One aspect I see that is not covered is if the references would work in
Hi,
On Wed, 2011-06-08 at 12:04 +0200, Johannes Schlüter wrote:
>
> Having the behavior cleared I wonder how useful it is in practical
> terms. A class type hint guarantees me I can do a specific call to
> methods defined in the class/interface. The proposed type hint tells
> me
> I can call it i
Well, I generally think that PHP should be less strict about reserved
keywords. The number
of reserved keywords increases with every further release of PHP. For
example PHP 5.4
introduces "trait" and "insteadof". PHP 5.3 introduced even more. Every new
keyword PHP
introduces both breaks old code an
Am 10.07.2011 19:03, schrieb Philip Olson:
> What this means to ext/mysql:
>
> - Softly deprecate ext/mysql with education (docs) starting today
> - Not adding E_DEPRECATED errors in 5.4, but revisit for 5.5/6.0
> - Add pdo_mysql examples within the ext/mysql docs that mimic the current
>
Greetings PHP geeks,
Don't panic! This is not a proposal to add errors or remove this popular
extension. Not yet anyway, because it's too popular to do that now.
The documentation team is discussing the database security situation, and
educating users to move away from the commonly used ext/mys
There's going to be a ton of code in the wild that will break if primitive
types become reserved words.
On Sun, Jul 10, 2011 at 11:41 AM, Patrick ALLAERT wrote:
> 2011/6/17 Stas Malyshev :
>
> [snip]
>
> > 2. Make primitive type names reserved words (in case we ever want some
> form
> > of scalar
2011/6/17 Stas Malyshev :
[snip]
> 2. Make primitive type names reserved words (in case we ever want some form
> of scalar typing or anything else with scalar types). Using them as
> identifiers would return parse error for now. May have BC implications.
I am not sure it is a good idea to make t
33 matches
Mail list logo