+1
Denis
Da: "Will Fitch"
A: "Zeev Suraski"
Cc: guilhermebla...@gmail.com, "PHP internals"
Inviato: Martedì, 16 novembre 2010 8:43:39
Oggetto: Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support
discussion
Your answer should have been just that. The overwhelming majori
Your answer should have been just that. The overwhelming majority amongst
the principal developers of PHP voiced an opinion against it. I can
certainly understand the need for a meritocracy in PHP's current state. The
benefit of annotations for the masses vs performance hit and complexity
isn't c
( Try again Zeev changing the pigging address ;) )
Zeev Suraski wrote:
I hope I won't stir the pot too much, but with all due respect to the vote of
at-best a two digit subset of an arbitrary 3000+ subscribers to internals,
there's an overwhelming majority amongst the principal developers of PH
If past experience is any indicator then you’re hardly correct regarding your
first statement – being able to do something in PHP was no insurance against
proposals suggesting new ways of doing the same thing – often in an improved
way.
Re: the 2nd part, extending phpdoc would be way less obscu
On Tue, Nov 16, 2010 at 8:06 AM, Zeev Suraski wrote:
> > -Original Message-
> > From: Pierre Joye [mailto:pierre@gmail.com]
> > Sent: Tuesday, November 16, 2010 1:45 AM
> > To: Zeev Suraski
> > Cc: guilhermebla...@gmail.com; PHP internals
> > Subject: Re: [PHP-DEV] PHP 5.4 - Meta attr
I hope I won't stir the pot too much, but with all due respect to the vote of
at-best a two digit subset of an arbitrary 3000+ subscribers to internals,
there's an overwhelming majority amongst the principal developers of PHP that
voiced an opinion against it. While we have no official rules or
> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: Tuesday, November 16, 2010 1:45 AM
> To: Zeev Suraski
> Cc: guilhermebla...@gmail.com; PHP internals
> Subject: Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support
> discussion
>
> On Tue, Nov 16,
On 11/15/10 10:12 PM, Stas Malyshev wrote:
> Hi!
>
>> Well, it changes the signature of that function, so while we don't break
>> backward binary compatibility, we break forward compatibility within the
>> 5.3 branch. As in, if I change my extension to use this new NoNull
>> string flag, it will
Hi!
Well, it changes the signature of that function, so while we don't break
backward binary compatibility, we break forward compatibility within the
5.3 branch. As in, if I change my extension to use this new NoNull
string flag, it will no longer work on<5.3.3 whereas if I do the
if(strlen(fil
> -Original Message-
> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
> Sent: Monday, November 15, 2010 9:25 PM
> To: Andi Gutmans
> Cc: Stas Malyshev; internals
> Subject: Re: [PHP-DEV] Adding path_len to all stream functions in trunk
>
> Well, it changes the signature of that function,
On 11/15/10 9:16 PM, Andi Gutmans wrote:
>> -Original Message-
>> From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
>> Sent: Monday, November 15, 2010 8:21 PM
>> To: Rasmus Lerdorf
>> Cc: internals
>> Subject: Re: [PHP-DEV] Adding path_len to all stream functions in trunk
>>
>> Hi!
>>
>>>
> -Original Message-
> From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
> Sent: Monday, November 15, 2010 8:21 PM
> To: Rasmus Lerdorf
> Cc: internals
> Subject: Re: [PHP-DEV] Adding path_len to all stream functions in trunk
>
> Hi!
>
> > Ok, I went through all the 5.3 code. This shou
Hi!
Yeah, I thought about that too. Still not something we can do without
breaking binary compatibility in the 5.3 branch though and I really
would like to at least get all the core functions to guard themselves
against null-poisoning there.
How adding a new option char to zend_parse_paramete
On 11/15/10 8:21 PM, Stas Malyshev wrote:
> Hi!
>
>> Ok, I went through all the 5.3 code. This should fix the null poisoning
>> problems in 5.3 without breaking binary compatibility:
>>
>> http://progphp.com/nullpatch.txt
>
> Looking at this patch, I wonder if it wouldn't be cleaner to add new
>
Hi!
Ok, I went through all the 5.3 code. This should fix the null poisoning
problems in 5.3 without breaking binary compatibility:
http://progphp.com/nullpatch.txt
Looking at this patch, I wonder if it wouldn't be cleaner to add new
type (string without nulls) in parameter parsing and have
2010/11/16 Pierrick Charron :
> +1
+1 for annotations in 5.4
--
regards,
Kalle Sommer Nielsen
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
To help keep track of votes I made a public Google doc:
https://docs.google.com/document/d/11I7noRyNPbmgeFc1OSAFZfCfY3w3U4kNHpTVds09JCw/edit?hl=en
I have recorded the 4 so far, but everytime you vote--or if you notice
someone voted and didn't record it on the Google doc, please record it.
Thi
In conjunction to my vote, I really think Pierrick's proposal and patch is
worth another look if we talk implementation.
On Mon, Nov 15, 2010 at 8:43 PM, Pierrick Charron wrote:
> +1
>
> On 15 November 2010 21:27, guilhermebla...@gmail.com <
> guilhermebla...@gmail.com> wrote:
>
> > @Zeev: That t
+1
On 15 November 2010 21:27, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> @Zeev: That topic was related to an already built patch, which some
> where in favor, some against. That discussion lead to nowhere.
> So I opened a thread topic by topic for some democracy approval. As
+1 here.
I'd love to see the conversation of implementation.
On Mon, Nov 15, 2010 at 8:36 PM, Alec wrote:
> I forgot my vote too: +1
>
>
> On 11/15/2010 9:27 PM, guilhermebla...@gmail.com wrote:
>
>> @Zeev: That topic was related to an already built patch, which some
>> where in favor, some aga
I forgot my vote too: +1
On 11/15/2010 9:27 PM, guilhermebla...@gmail.com wrote:
@Zeev: That topic was related to an already built patch, which some
where in favor, some against. That discussion lead to nowhere.
So I opened a thread topic by topic for some democracy approval. As
soon as we reach
@Will: Patch works perfectly with PHP 5.3. There is just a minor issue
related to APC not caching instances.
That patch didn't reach a consensus and that's why I opened a
different thread to implement a patch based on poll results.
Cheers,
On Mon, Nov 15, 2010 at 10:55 PM, Will Fitch wrote:
> Wo
@Zeev: That topic was related to an already built patch, which some
where in favor, some against. That discussion lead to nowhere.
So I opened a thread topic by topic for some democracy approval. As
soon as we reach some reasonable consensus, we can start another patch
implementation based on what
Mostly it is that a new syntax will confuse people and add complexity
that PHP doesn't need. The same people don't believe that annotations
bring value worthy of adding a new syntax. Short array notation and
similar are noted as precedence.
That is a bulk of the arguments, but if I have forgot
Wow. I should actually look at the RFCs more frequently.
I have to say, assuming the patch is valid for PHP 5.3 (which I have no
doubt it is), I don't see why this can't be taken more seriously. I know
the discussion was brought up a few weeks ago, but what are the objections
to injecting this fu
The patch is already written and a RFC created by Guilherme:
http://wiki.php.net/rfc/annotations .
I personally think annotations could make a *great* addition to PHP.
I agree with Will that annotations are especially useful for SOAP and
XML-RPC. I personally think annotations are useful for A
I have certainly wanted them many times - especially when using SOAP.
Having WSDL auto-generation without compromising developer
documentation and attempting to have user-land code parse phpdoc for this
purpose seem{ed,s} counterintuitive. That said, introducing annotations is
a HUGE undertaking
On Tue, Nov 16, 2010 at 12:39 AM, Zeev Suraski wrote:
> Suggesting phpdoc is used for the purposes mentioned does not mean we don't
> understand what we're talking about.
I feel like you never used annotations in other languages, did you?
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.ne
Suggesting phpdoc is used for the purposes mentioned does not mean we don't
understand what we're talking about.
Zeev
> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: Tuesday, November 16, 2010 12:43 AM
> To: Zeev Suraski
> Cc: guilhermebla...@gmail.com; PH
hi,
The good reason is to actually understand what we are talking about.
And seeing phpdoc mentioned in almost all replies tell me that we
don't.
On Mon, Nov 15, 2010 at 11:22 PM, Zeev Suraski wrote:
> I don't see a point in repeating the discussion we've already had on that
> topic several wee
I don't see a point in repeating the discussion we've already had on that topic
several weeks ago. There needs to be an overwhelmingly good reason to add a
brand new syntax to the language, a whole branch of it in the case of
annotations - and there simply isn't.
Zeev
> -Original Message-
On Fri, Nov 12, 2010 at 12:10 PM, Jonah H. Harris wrote:
> RFC updated with links to GCC, Python, and Ruby syntax definitions.
>
I just noticed the patch (written against 5.3) doesn't apply cleanly to
trunk and will be updating that shortly. In that same vein, I wanted to
confirm whether the pro
Hi folks,
I'll start a series of topics (in this thread) about meta attribute
(aka. Annotations) discussion.
So as soon as we agree on each topic I'll open another point to be discussed.
Only when we reach some consensus I'll open another topic discussion.
I suggest to have a poll for each topic,
Em 15 de novembro de 2010 14:49, Gustavo Lopes escreveu:
> On Mon, 15 Nov 2010 08:25:44 +0100, Kalle Sommer Nielsen
> wrote:
> > Hi
> >
> > 2010/11/15 Gustavo André dos Santos Lopes :
> >> cataphract Mon, 15 Nov 2010 03:05:32
> +
> >>
> >> Revision: http://svn.ph
On Mon, 15 Nov 2010 08:25:44 +0100, Kalle Sommer Nielsen
wrote:
> Hi
>
> 2010/11/15 Gustavo André dos Santos Lopes :
>> cataphract Mon, 15 Nov 2010 03:05:32
+
>>
>> Revision: http://svn.php.net/viewvc?view=revision&revision=305346
>>
>> Log:
>> - Added leak_varia
hi Rasmus,
Thanks for the patch! It is great for 5.3 (this problem has been an
issue for too long already).
However I would like to change the APIs in trunk accordingly to avoid
to have checks in every single place where path are used, and indeed
to avoid to have bugs in new codes. In short, it s
Ok, I went through all the 5.3 code. This should fix the null poisoning
problems in 5.3 without breaking binary compatibility:
http://progphp.com/nullpatch.txt
There are quite a few places where we can't solve it centrally, so
perhaps we need to take the same approach in trunk.
This should take
37 matches
Mail list logo