Hi Rasmus,
Thanks for the highlight.
My biggest concern about all this breakage done for NG could somehow be
minimized by providing possible alternate implementations that could work
both backwards compatible and forwards compatible?
I just don't want to work on extensions I support that would nev
Hi all,
I already said before and I'm happy to say it again...
Whenever you feel ready to get true, complete Annotations into core, just
tell me and I'll be ready to work on previously suggested Annotations in
sync with current internals.
Cheers,
On Thu, Feb 5, 2015 at 11:00 PM, Pierre Joye wro
ly changed over time and we now have it return only its FQCN.
[]s,
On Thu, Feb 5, 2015 at 11:10 PM, Pierre Joye wrote:
> On Fri, Feb 6, 2015 at 11:08 AM, guilhermebla...@gmail.com
> wrote:
> > Hi all,
> >
> > I already said before and I'm happy to say it again...
Hi Dmitry,
Last time we discussed was this one: https://wiki.php.net/rfc/annotations
The ideal one was the version before:
https://wiki.php.net/rfc/annotations?rev=1300089833
To have this in core, we need to step back and re-evaluate how we could
achieve 80% minimum. My original proposal was tryi
Dmitry,
Doc comments are terrible. I really want you to spend some time looking at
what we had to do inside of Doctrine Annotations to make it work. We have
to token_get_all() the file to be processed and track for "use"s to allow
importing inside of doc blocks. We also had to build a top-down rec
hould be placed.
[]s,
On Fri, Feb 6, 2015 at 10:12 AM, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> Dmitry,
>
> Doc comments are terrible. I really want you to spend some time looking at
> what we had to do inside of Doctrine Annotations to make it work. We
Hi Dmitry,
So, can we start drafting out some things?
Simple questions would help everybody to get this moving forward.
I'll compile a simple list of questions to answer that would drive the
direction on how it would be implemented.
Please ignore the formatting on HOW they are defined. Tokens can
Hi Yasuo,
Design by Contract could be used at the top of Annotation if (and only if)
it also had support for Interceptors. Since it could potentially be a
nightmare for PHP, I don't think it's time to propose something at the top
of another thing that is still far from being reality.
It would foll
, Yasuo Ohgaki wrote:
> Hi Guilherme,
>
> On Mon, Feb 9, 2015 at 11:58 AM, guilhermebla...@gmail.com <
> guilhermebla...@gmail.com> wrote:
>
>> Design by Contract could be used at the top of Annotation if (and only
>> if) it also had support for Interceptors. Since
Hi,
I read again and again the RFC and I just decided to switch my vote.
Originally a "YES" voter, I'm now a "NO" voter. I still want strict types
to exist in PHP, and not only at the end-user level, but also at the
internals level (I can see so many optimizations around...).
However, I think it's
gt;
> > On 9 Feb 2015, at 18:12, guilhermebla...@gmail.com wrote:
> >
> > I read again and again the RFC and I just decided to switch my vote.
> > Originally a "YES" voter, I'm now a "NO" voter. I still want strict types
> > to exist in PHP, and
François,
Doctrine relies on nested annotations for a variety of mapping information.
One example:
http://doctrine-orm.readthedocs.org/en/latest/reference/association-mapping.html#one-to-many-unidirectional-with-join-table
[]s,
On Tue, Feb 17, 2015 at 4:33 PM, François Laupretre
wrote:
> Hi A
Hi Dmitry,
> Are you (and Doctrine team) interested in this annotation idea?
I'd say that Benjamin nailed in our possible usage:
class Foo {
}
Now I do feel we need to elaborate some sort of named parameters. Doctrine
tries to simplify a lot developer's life by using consistency in default
map
Hi internals,
I came really close to reach the final state of my to be proposed "private
class, interface and trait" support here.
However, I have a bug under this circumstance:
https://gist.github.com/guilhermeblanco/3392925014c9f8374acc
I'd love if someone could give me a hand on how could I ge
+1 on Sebastian's suggestion. =)
I volunteer to either update the RFC or create a new one to resolve this
once "Exceptions in the engine" passes (which looks like a reality already
to me).
Just tell me which approach I should take and I'll happily write the RFC.
[]s,
On Fri, Feb 27, 2015 at 9:4
@Rasmus:
I don't see what's the problem of aliasing functions for the next 1-2
majors, deprecate the inconsistent one in the following and remove later.
On Wed, Mar 4, 2015 at 10:33 AM, Trevor Suarez wrote:
> ... well that's a constructive way of going about it. I don't think Yasuo
> did anythi
Hi internals,
I carefully read all 3 proposed RFCs related to scalar type hints.
As an end user and enthusiast of the language, I want PHP to always
improve. STH is *the* major inclusion for PHP 7 and no matter how many
people say about phpng performance, STH is the one that will impact mostly
eve
+1 on this, as this is more inline with how ZPP currently works, creating
less headaches to end users.
On Fri, Mar 13, 2015 at 2:33 PM, Stelian Mocanita wrote:
> So to get it clear for everyone: the right way is for internals to ignore
> community as a
> whole, stick to their own views and imple
, 2015 at 9:44 PM, Zeev Suraski wrote:
> >
> > > > -Original Message-
> > > > From: Derick Rethans [mailto:der...@php.net]
> > > > Sent: Friday, March 13, 2015 10:34 PM
> > > > To: guilhermebla...@gmail.com; Stelian Mocanita
And none answered me... is this RFC gonna be allowed to enter on voting
phase for 7.0 or not?
This drastically changes my voted on STH v5 which ends EOD today.
[]s,
On Fri, Mar 13, 2015 at 6:17 PM, Stelian Mocanita wrote:
> Zeev, allow me to understand how this goes. Bob's discussions on the R
I'll switch my vote on STH v5 to YES.
If we get Basic STH into voting phase, I change my vote to NO and vote on
YES on Basic STH.
[]s,
On Fri, Mar 13, 2015 at 6:35 PM, Pierre Joye wrote:
> On Mar 14, 2015 9:24 AM, "Zeev Suraski" wrote:
> >
> > > -Original Message-
> > > From: stelian.
What about JsonDeserializable? I would like to have the choice to have a
serialize-only operation.
On Mon, Jul 13, 2015 at 10:13 AM, Dean Eigenmann
wrote:
> The Additional function you have proposed seems like the easiest and best
> way to do it currently without changing the language. I was thi
I have just one question, partially unrelated.
How can I make something similar to Interceptors of Java according to
your approach?
For those that have no idea, interceptors is a way to intercept
get/set of a property inside the class and act under this
circumstance.
[]s,
On Sun, Dec 11, 2011 at
und
> this approach will be changing or augmenting an existing property that is not
> public. If you wanted to modify this interception, you'd need to extend the
> class using it and redefine the getter and/or setter.
>
>
> On Dec 11, 2011, at 10:02 PM, guilhermebla..
Hi,
I don't see how we could possibly do as option 1.
The structure would be weird, because considering I'm looking for an
specific ReflectionMethod that matches a property name, I'd also be
able to call it through invoke, but also regularly through
$obj->Setter($value);
Since I don't see in the m
More info about it: https://news.ycombinator.com/item?id=6604156
On Thu, Oct 24, 2013 at 7:40 AM, Lester Caine wrote:
> Thomas Hruska wrote:
>
>> and again waiting up to 48 hours to be removed globally.
>>
>
> If it is only 48 hours ... took over two weeks to sort one of my customers
> sites th
OMG, so +1 on this! *rolling eyes*
We'd be a step away for hookable grammars! \o/
On Thu, Jul 31, 2014 at 2:27 PM, Michael Wallner wrote:
> On 31 July 2014 20:11, Nikita Popov wrote:
>
> > Hi internals!
> >
> > I've created a draft RFC and implementation for the introduction of an
> > Abstract
When is this planned to go through voting process?
On Sat, Aug 2, 2014 at 5:27 PM, Andrea Faulds wrote:
> Hi!
>
> On 2 Aug 2014, at 21:44, Nikita Popov wrote:
>
> > Why do you think this isn't a good idea? I think it would be a nice way
> to prototype language features before pulling them into
Hi,
Since I don't know where you guys like to discuss implementations, I'm
pasting same thing I did in php-src PR:
I'd propose instead of accepting "nowait" only, I'd use a better support
and accept "until", dealing with possible cases:
- -1: Blocks and wait until lock is acquired
- 0: Ex
Hi Matteo,
BSD does accept it as sem_timedwait, which I could find a reference for
FreeBSD:
http://www.freebsd.org/cgi/man.cgi?query=sema&sektion=9
Cheers,
On Tue, Sep 2, 2014 at 10:01 AM, Matteo Beccati wrote:
> Hi,
>
> On 02/09/2014 15:38, guilhermebla...@gmail.com wrote:
&g
.html
On Tue, Sep 2, 2014 at 10:46 AM, Matteo Beccati wrote:
> On 02/09/2014 16:39, guilhermebla...@gmail.com wrote:
> > Hi Matteo,
> >
> > BSD does accept it as sem_timedwait, which I could find a reference for
> > FreeBSD:
> >
> > http://www.freebsd.org/cgi/
After discussing with Matteo, I realized I was referring to POSIX
sempahores and not to System V.
Patch looks ok to me.
Is it possible to have this merged?
Thanks,
On Tue, Sep 2, 2014 at 11:03 AM, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> It's also support
Hi,
Here is a new RFC: https://wiki.php.net/rfc/sync
Thoughts appreciated.
Cheers,
--
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
uot; section.
>
> Why is this good for PHP?
> Why will a significant percentage of users be interested in this?
> Why is it necessary?
>
> This feel pretty niche to me.
>
> -Sara
>
> > On Sep 30, 2014, at 4:06, "guilhermebla...@gmail.com"
extension or
not, it's not a good argument to say join/no join.
On Tue, Sep 30, 2014 at 4:05 PM, Andrea Faulds wrote:
>
> On 30 Sep 2014, at 20:56, guilhermebla...@gmail.com wrote:
>
> >> Isn't this extension a bit "young" to join php core ?
> >
> >
Hi,
Ferenc nailed why this RFC could be considered invalid. Maintenance burden
and separate releases would be bad if tied to php-src. I'll update its
status to declined.
Joe, as I said in the RFC, Mutex could only be supported through pthreads
PECL.
So your answer was still not 100% accurate from
Hi Levi,
This RFC is pretty consistent, small and focused on a specific part of the
overall previously desired support.
I do think many more subsequent RFCs would come up after this one to expand
return typehint support, but as it stands right now is extremely good. Any
further inclusion would dra
Hi,
As one of the original authors of both Doctrine Annotations and previous
RFC of native Annotations in PHP, I can go thoroughly on every specific
detail about challenges of design decisions to make.
Primarily, I do not see docblocks as the right place to store class'
metadata information. Meta
Hi,
By dealing with annotations in docblocks will force the Annotations parser
to *much* smarter than you imagine.
Currently in Doctrine Annotations implementation, @param and @Param are
considered different not only by first character to be uppercased, but
rather because a class also exist in th
/annotations/blob/master/lib/Doctrine/Common/Annotations/DocParser.php#L631
[]s,
On Tue, Nov 4, 2014 at 5:42 PM, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> Hi,
>
> By dealing with annotations in docblocks will force the Annotations parser
> to *much* smarte
Hi internals,
Library developers sometimes plan for extensibility of their code, but not
all pieces are able to be extended and unexpected usage can lead to
unpredictable behavior.
Based on that, I consider it may be a good addition to PHP to add class
visibility support and enhance existing modif
t may not be a sane approach.
[]s,
On Tue, Nov 18, 2014 at 12:58 PM, Andrea Faulds wrote:
>
> > On 18 Nov 2014, at 17:33, guilhermebla...@gmail.com wrote:
> >
> > Library developers sometimes plan for extensibility of their code, but
> not
> > all pieces are able
Hi,
I worked on an implementation of a somehow controversial concept that
exists in hack and C#: abstract final classes.
https://wiki.php.net/rfc/abstract_final_class
My motivation is to further expand class support to add modifiers (PPP -
public, protected, private). I added this change to init
I added these checks together
with static properties here:
- Properties:
https://github.com/php/php-src/pull/923/files#diff-3a8139128d4026ce0cb0c86beba4e6b9R4251
- Methods:
https://github.com/php/php-src/pull/923/files#diff-3a8139128d4026ce0cb0c86beba4e6b9R3936
I'm able to expand the RFC i
rosoft.com/en-us/library/79b3xss3.aspx Now it's funny that
C# also accepts "abstract final" with the same idea/concept of their
documentation of static classes. #weird
[]s,
On Thu, Nov 27, 2014 at 10:06 AM, Rowan Collins
wrote:
> guilhermebla...@gmail.com wrote on 27/11/2014 14:
Ok... so if I update the RFC to be "static class", does that make everybody
happy?
I mainly wanna get this forward thinking trend... =)
On Thu, Nov 27, 2014 at 10:49 AM, Rowan Collins
wrote:
> guilhermebla...@gmail.com wrote on 27/11/2014 15:34:
>
>> > This is true
Hi Andrea,
Thanks a lot for putting efforts thinking through this problem.
Indeed we have 3 problems that leads to "static classes". You detailed 2 of
them.
The third is around encapsulation. I may want functions that are reused by
other functions at the namespace level, but that shouldn't be used
I'm working on a patch right now and I removed the implicit configuration
of static to methods.
It's only missing reflection magic. Should be out of the oven in one hour
or less.
On Mon, Dec 1, 2014 at 2:44 PM, Lars Strojny wrote:
> Hi Guilherme, hi Robert.
>
> > On 01 Dec 2014, at 14:58, Robert
PR with this feature request: https://github.com/php/php-src/pull/929
On Mon, Dec 1, 2014 at 4:56 PM, Rowan Collins
wrote:
> On 1 December 2014 20:30:46 GMT, Andrea Faulds wrote:
> >
> > The problem is that, well, global state is rarely a good thing, I don’t
> think we should be encouraging it.
Yes, C# documented here:
http://msdn.microsoft.com/en-us/library/79b3xss3.aspx
On Mon, Dec 1, 2014 at 5:41 PM, Levi Morrison wrote:
> Perhaps I have missed it in the noise, but have any other mainstream
> languages (or new hipster ones; I don't care) have something
> equivalent to the proposed s
Hi,
I made some improvements that would like to get merged into PHP, but I
require someone with Zend karma to review and merge.
The patches are all related and included in each other as a progressive
effort.
As a quick explanation, the removal of ZEND_ACC_FINAL_CLASS addresses some
classes that we
On Wed, Dec 3, 2014 at 8:06 PM, Levi Morrison wrote:
> The parser changes need to be careful reviewed; I don't have time at
> the moment to verify it but I think you unintentionally allowed some
> syntax's that shouldn't be valid because of the addition to
> `inner_statement`.
>
Shouldn't. I bro
here's another one in the oven, which prevents extension developers to
create classes that extends traits or interfaces.
This is currently supported only for userland classes, but not for Zend API.
Cheers,
On Wed, Dec 3, 2014 at 8:39 PM, guilhermebla...@gmail.com <
guilhermebla...@gmail.com&g
Hi Dmitry,
As I said, these patches are not huge beneficial, but enablers. Enablers in
the sense that further development over class/interface/trait simplified.
It's not a short win benefit, but a mid/long term.
Also defer currently checks done in zend_compile to Bison (such as trait
extends and
Nikita,
Shouldn't #3 make more sense taking into consideration this commit:
https://github.com/guilhermeblanco/php-src/commit/872a97c8dbc1c8823985d9a0305938c508865a0d
It is part of a followup PR https://github.com/php/php-src/pull/937 that
removes compiler code checks and delegates to bison, since
Seems good for me. =)
On Wed, Dec 10, 2014 at 10:27 AM, Dmitry Stogov wrote:
> Hi,
>
> Please, review the following patch
> https://gist.github.com/dstogov/fba2cc621ef121826efe
>
> It's huge, but actually, only changes in zend_compile.h are matter. The
> rest is obvious renaming.
>
> the main id
Hi,
Not trying to demerit the proposal, but accepting ?-> and black magic just
seems wrong, very wrong.
You need to write defensive code, not rely on the language to do that for
you.
[]s,
On Thu, Dec 11, 2014 at 2:35 AM, Stanislav Malyshev
wrote:
> Hi!
>
> > First, how is this substantially di
IIRC, we used to support that back in ~2000s, but it got removed based on
the lack of usage and poor implementation.
Connection pooling could be a good usage of this if we manage to get this
working again.
[]s,
On Thu, Dec 11, 2014 at 1:46 PM, Marc Bennewitz wrote:
>
> Am 10.12.2014 um 09:53 s
Hi internals,
After a good round of discussion, I updated the original "abstract final
class" proposal into a "static class" proposal.
However, I kept both patches online so it's up to voters decide which one
it could be implemented.
Patches are now complete and voting phase starts now and will be
It's part of the history of that RFC, accessible here:
https://wiki.php.net/rfc/abstract_final_class?rev=1417060830
On Fri, Dec 12, 2014 at 11:18 AM, Florian Margaine
wrote:
>
> Hi,
>
>
>
> On Fri, Dec 12, 2014 at 5:12 PM, guilhermebla...@gmail.com <
> guilhermebla.
RFC is updated exposing both possible usages with both explanations.
Hope it doesn't confuse even more.
On Fri, Dec 12, 2014 at 11:30 AM, Florian Margaine
wrote:
>
> Hi,
>
> Le 12 déc. 2014 17:28, "guilhermebla...@gmail.com" <
> guilhermebla...@gmail.com>
> On Tue, Dec 16, 2014 at 9:39 AM, Matteo Beccati
wrote:Hi Guilherme,
>
>> On 16/12/2014 12:34, Guilherme Blanco wrote:
>> Hi,
>> All I can say is that the lack of this feature is one of the main
reasons why Doctrine doesn't fully work with composite keys.
>> With this enhancement it would now bec
Hi,
Answering the question of Christopher Becker. It is not possible to
traverse and get your desired elements.
How would you achieve a foreach by key (returning object) without having to
store a separate list and track by hash or through an interface?
Cheers,
On Wed, Dec 17, 2014 at 10:04 AM, D
Hi,
I originally considered you could retrieve the object key, but if it is not
possible by this RFC, I will switch my vote to no.
By storing hash one way it introduces a huge wtf to the language.
Cheers,
On Dec 17, 2014 8:40 PM, "Rowan Collins" wrote:
> On 17/12/2014 22:05, Rowan Collins wrot
at 6:54 PM, Pascal Martin, AFUP <
mail...@pascal-martin.fr> wrote:
>
> On 12/12/2014 17:12, guilhermebla...@gmail.com wrote:
>
>> Patches are now complete and voting phase starts now and will be active
>> until 12/19/2014.
>>
>> https://wiki.php.net/rfc/abstract_fin
at 00:35, guilhermebla...@gmail.com wrote:
> >
> > RFC is updated exposing both possible usages with both explanations.
> > Hope it doesn't confuse even more.
>
> Hi, in your "As static class” example, it doesn’t really demonstrate that
> you can omit the “static” mod
Hi internals,
I finalized a new proposal for PHP. It consists into adding support for
package-private classes in the language.
A package private class is basically a class that can only be instantiated
in its declared namespace. This means that you cannot extend, implement or
use a class, interfa
+1 for adding E_DEPRECATED and removing support in PHP 8.
On Mon, Dec 22, 2014 at 11:17 PM, Ferenc Kovacs wrote:
> On Sat, Dec 20, 2014 at 11:01 PM, F & N Laupretre
> wrote:
>
> > Hi,
> >
> >
> >
> > I don't know if this was discussed before. So, tell me what you think
> > before
> > I write an
Hi Robert,
Answers inline.
On Tue, Dec 23, 2014 at 7:59 AM, Robert Stoll wrote:
>
>
> > -Ursprüngliche Nachricht-
> > Von: Leigh [mailto:lei...@gmail.com]
> > Gesendet: Dienstag, 23. Dezember 2014 04:34
> > An: guilhermebla...@gmail.com
> > Cc: PHP
Hi,
-1 on this proposal
+1 on named parameters
As of for this...
> > handy and easier. I could dig the archives but I don't remember what
> > was the reason why we rejected the idea back then.
>
> Bikeshedding about the syntax mostly, but that all pales compared to
> amount of work that needs t
Hi Stas,
As I said, we should look at that patch as we implemented Named Parameters
there with everything you mentioned.
Cheers,
On Wed, Jan 14, 2015 at 3:23 PM, Stanislav Malyshev
wrote:
> Hi!
>
> > -1 on this proposal
> >
> > +1 on named parameters
>
> Come on, we've already talked about it
Cof... cof...
https://wiki.php.net/rfc/annotations
Good luck convincing php-src folks.
You'd be my hero.
On Mon, Jan 7, 2013 at 9:50 PM, Rasmus Schultz wrote:
> On parsing annotations in docblocks: please don't.
>
> First of all, there are already plenty of established userland
> implementati
Hi internals,
Just like before, people are confusing documentation support with
behavioral support.
No matter what people say, documentation is documentation and code still
behaves the same with and without the comment docblock. When talking about
behavioral marks, removing that piece makes your c
Hi,
At the time Pierrick and I worked on annotations patch, we couldn't use
some of the operators due to many different reasons:
@ = error supressing
[] = short array syntax
{} = scopr creation
: = all sorts of problems you can imagine
& = array referencing
We actually found that <> was allowed,
But I can add more.
Filtering
Validation
Form declaration
Database mapping
Joinpoint definitions (AOP)
Service Injection (look at FLOW3)
Testing
etc
Basically everything can define constraints or usage of an element,
behavior, process or nature of an element.
Let me give some individual examples:
Pierrick, before update v3 of patch, let's first clarify things that need
to be discussed.
Rasmus, you have no idea how happy you made me for a gentle comment
pointing something we should think before propose a patch instead of on
(sorry for the wording) bitching about the idea.
There're tons of e
ay. I suppose the same could be
> said of applying it to a class.
>
> In essence though, this prior revision is exactly the kind of thing that I
> would be interested in if we could get past the parsing issues...
>
>
> On 1/9/2013 1:57 PM, guilhermebla...@gmail.com wrote:
&
I'd love if Stas, Derick, Rasmus or Zeev comment here on criteria about
acceptance of new features.
You all claim that PHP is simple, that features include should be widely
used and only important functions, classes that have regular and extensive
usage would be in.
I wonder how Annotations is dif
We all agree that nullable properties need to be addressed.
Now why just don't discuss a possible syntax and move on?
Initializers, parenthesis around unsetters, etc can all be detailed and
discussed later.
Here are the proposed syntaxes:
public DateTime? $date {
get { ... }
set { ... }
}
pu
Stas,
I totally agree and Pierrick and I faced all these problems during the
creation of patch.
If PHP doesn't all have support required for a given feature, let's just
not only discuss feature, but also the required support too. Named
parameters is a great example. I'd also name another one,
Refl
Not really insane.
PHPPHP is very powerful. Imagine someone that have no idea about C but
would love to propose something.
Just fork the project, add the desired support in PHP and propose here. I
guarantee it'll be easier to understand the caveats and the final patch
easily.
Cheers,
On Sat, Ja
+1
On Feb 19, 2013 10:13 AM, "Cyberspice" wrote:
> On 19 Feb 2013, at 12:06, Sara Golemon wrote:
>
> > Opening RFC to allow trailing comma in function call argument lists
> >
> > https://wiki.php.net/rfc/trailing-comma-function-args
>
> +1
>
> Melanie
>
>
> --
> PHP Internals - PHP Runtime Deve
Nikita,
That's f*ckin' awesome. Thanks a lot!!!
Cheers,
On Tue, Jun 11, 2013 at 1:56 PM, Lars Strojny wrote:
> Thank you, thank you, thank you all!
>
> Am 10.06.2013 um 20:33 schrieb Nikita Popov :
>
> > Hi internals!
> >
> > We just published some rather extensive documentation on internal o
Hi Johannes,
I do understand motivations behind keeping core simple and stable that
majority of internals always promote. I also understand the majority of
user base is on shared host.
But as a counterpart, what about large agencies that do want to extract
every single feature PHP has to provide?
Hi Derick,
I'm all for it.
Although I have karma, I'm not an active PHP core contributor, but I
would like to participate of such discussion, mainly because I have
plenty experience with Annotations from another languages.
I'll spend some time re-reading the entire Annotations thread and come
up
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,
whole branch of it in the case of
> annotations - and there simply isn't.
>
> Zeev
>
>> -Original Message-
>> From: guilhermebla...@gmail.com [mailto:guilhermebla...@gmail.com]
>> Sent: Monday, November 15, 2010 7:08 PM
>> To: PHP internals
>> Sub
@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
to what people want. I already restricted the counting of
votes to people with PHP karma, so meritocracy is perfectly being
counted here.
Please stick to your vote and let other people vote. Do not close this
thread, again.
Cheers,
>
> Zeev
>
>> -Original Message-
>
Hi Lester,
If you READ my first email of this thread, you'll find out I do not
speak about new syntax, etc.
No matter if you say "that can be done through docblock", you're
automatically saying +1 to this thread.
Please re-read the topic and vote. Thanks.
Cheers,
On Tue, Nov 16, 2010 at 5:38
@Chad: You're getting me wrong here.
If results of poll decide for OK to meta attribute support, next poll
would be which implementation to choose.
I can find 3 different implementations that we can choose, but anyone
is free to contribute.
- Docblock
/** @Foo */
class User { ... }
- New syntax
ccept
global decisions.
Cheers,
On Tue, Nov 16, 2010 at 3:47 PM, guilhermebla...@gmail.com
wrote:
> @Chad: You're getting me wrong here.
>
> If results of poll decide for OK to meta attribute support, next poll
> would be which implementation to choose.
> I can find 3 different im
Hi Stas,
A full RFC will be written based on results of polls.
I'm able to write 10 RFC's, but none will care until we reach this
list with a patch.
So instead of lose time, I prefer to discuss what can be done here,
write an RFC then finally implement it.
But without having feedback from core de
Hi Stas,
Ok, so you think I should just consider everyone want some sort of
meta attribute support and start discussing the topics?
Should I separate it in different threads or put it all here?
The subject is big and I identify at least 5 different discussions
that can diverge.
Cheers,
On Wed,
Metadata doesn't have value.
>
> What are the 5 different discussion topics you are thinking of, just out of
> curiosity?
>
> Also, I can just post my syntax idea as a gist or pastie or something
> instead of making an rfc...
>
> -Alec
>
> On 11/16/2010 9:29 PM, guil
Hi Gustavo,
Normal instantiation cannot be done.
Here is a sample where it would fail:
new Foo()
class User { ... }
So it must be something different.
[]s,
On Wed, Nov 17, 2010 at 1:07 AM, Gustavo Lopes wrote:
> On Wed, 17 Nov 2010 01:54:22 -, Stas Malyshev
> wrote:
>
>> The problem is n
Hi Larry,
For existent project examples and usage, here are 2 links of the
upcoming versions of Doctrine 2 and Symfony 2:
http://www.doctrine-project.org/projects/orm/2.0/docs/reference/basic-mapping/en#introduction-to-docblock-annotations
http://docs.symfony-reloaded.org/guides/validator.html
P
d.org/guides/validator.html (at the end of
HTML file)
Cheers,
On Thu, Nov 18, 2010 at 3:00 PM, la...@garfieldtech.com
wrote:
> On 11/18/10 7:34 AM, guilhermebla...@gmail.com wrote:
>>
>> Hi Larry,
>>
>> For existent project examples and usage, here are 2 links of the
&g
heers,
On Tue, Nov 16, 2010 at 10:32 AM, Richard Quadling wrote:
> On 16 November 2010 07:06, Zeev Suraski wrote:
>>> -Original Message-
>>> From: Pierre Joye [mailto:pierre@gmail.com]
>>> Sent: Tuesday, November 16, 2010 1:45 AM
>>> To: Zeev Su
+1 for next major, but not for middle point release. =)
2010/11/29 Pierre Joye :
> my +1 for new major version only, btw :)
>
> 2010/11/27 Pierre Joye :
>> +1 if "While technically possible this RFC suggests that the following
>> shall NOT be valid for keeping the code readable " also means that t
1 - 100 of 221 matches
Mail list logo
