Re: [PHP-DEV] Cascade Operator (was Re: [PHP-DEV] Proposal for php7 class method return)

2016-07-11 13:30 GMT-03:00 Rasmus Schultz : > Regarding syntax - I feel the natural choice, e.g. similar to "." vs > "..", would be a longer arrow --> but that's ambiguous. (decrement > operator, greater than operator) > Yes, it's ambiguous. It will also get confused for the

Re: [PHP-DEV] [RFC] Simple Annotations

> << HttpMethod::post() >> // equivalent to static method-call > HttpMethod::post() > What would this, specifically, do? Would it call HttpMethod::post() when the class gets instantiated and return its return on a ReflectionClass::getAnnotations()? Why is it necessary to be able to evaluate

Re: [PHP-DEV] [RFC] Simple Annotations

I completely agree with Marco. Throwing class-loading errors for value-object classes is alright. For logic-parsing inside annotations, I don't feel any need for it. Metadata should be static, IMO, but it could very well be (and should be) value-objects. >At the end of the day, what we end up

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

The bottom line is that the only requisite for contributors is professionalism. People should keep non-work related issues to themselves inside the workplace, as well as they should be respectful to each other no matter what. However, if someone is professional and has never posted off-topic

Re: [PHP-DEV] Native Annotation Syntax

Hi, Rowan. I'll respond to some points that have become recurrent. 1) It's might not be objectively bad to add this feature in docblocks, but it will be objectively wrong to keep calling them "DocBlocks" if they are no longer documentation-only blocks. 2) Even though PHP already treats docblocks

Re: [PHP-DEV] Native Annotation Syntax

Hey, Rowan, don't apologize for making the case for what you believed to be the right way. I'm glad I could summarize my views in a way that you could agree with me. I've reread your point about the transpilers and obfuscators, and you're right, I misunderstood what you said. I'm sorry. Now, I'd

Re: [PHP-DEV] Native Annotation Syntax

Levi, I was asking about the reasons it was rejected. While researching, I found the original RFC was voted with 123 votes (71% approval), and yet was marked as 'declined'. I didn't know why, couldn't find why, so I figured I'd ask (as it strikes me as a major feature that's missing). 2015-11-26

Re: [PHP-DEV] Native Annotation Syntax

2015-11-25 13:47 GMT-02:00 Lester Caine : > Any new system would require > every third party tool to be adapted to use it > That's not true at all. A new syntax would in no way invalidate parsing annotations from docblocks. The only legacy code that is supported by IDEs (if

Re: [PHP-DEV] Native Annotation Syntax

Rowan, even if they are not harder, there is no reason to keep this feature in docblocks. Even the argument "compatibility with current implementations" is flawed, because there are many different implementations (not only doctrine's) with different syntaxes, so any native option would break SOME

Re: [PHP-DEV] Native Annotation Syntax

On top of it, it'd break obfuscators like Zend Guard. 2015-11-25 15:58 GMT-02:00 guilhermebla...@gmail.com < guilhermebla...@gmail.com>: > I can give you a good argument. > > opcache.save_comments=0 > > Make it work. > > On Wed, Nov 25, 2015 at 12:48 PM, Rowan Collins >

Re: [PHP-DEV] Native Annotation Syntax

I'd really like to see something outside the docblock. Comment annotations are a workaround for the lack of native annotations. It makes the environment hard to learn ("What does @param do? And what does @ManyToMany do?"), it makes it impossible for IDEs to hint/autocomplete without

[PHP-DEV] Native Annotation Syntax

Hello. I'd been reading some old RFCs recently, and I found two RFCs on the subject of annotations, both by Guilherme Blanco. The first one, which proposed a native syntax for annotations, is marked as 'declined', and I couldn't find a discussion for it anywhere. The second one, which proposes

Re: [PHP-DEV] [VOTE] Void Return Type RFC

Like I said in a previous post, there is no need to forbid using a void function return value. Throwing an E_NOTICE would be sufficient to inform the developer he's doing something weird (using the return value from a function that, by definition, shouldn't have any return value) without breaking

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

I've been thinking about what PHP should do when accessing the return value of a `void` function, and so far, I think the consistent thing should be to get NULL, while throwing an E_NOTICE. $a = $b; //$b wasn't initiated. This does the same thing. I tried accessing what was supposed to be

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

hould be assigned to $b, but an E_NOTICE is thrown. 2015-10-15 13:34 GMT-03:00 Andrea Faulds <a...@ajf.me>: > Hi Pedro, > > Pedro Cordeiro wrote: > >> I've been thinking about what PHP should do when accessing the return >> value >> of a `void` function, a

Re: [PHP-DEV] [RFC][DISCUSSION] Revisit trailing commas in function arguments

> Wouldn't this give the same benefit as trailing commas when it comes to > adding removing arguments - a single line diff? It would. However, I see some merit in someone wanting trailing commas for diffs. Leading commas would break away from PSRs and one should not have to choose between a