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

[Pedro Cordeiro]

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 (in)famous "goes to
operator":
http://stackoverflow.com/questions/1642028/what-is-the-name-of-the-operator

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

[Pedro Cordeiro]

> << 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 expressions on annotations? I do agree that throwing
errors/exceptions when classes are not found is needed (otherwise we wont
be able to use value-objects), but evaluating expressions seems a little
crazy for me... why should metadata be computed in runtime?

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

[Pedro Cordeiro]

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 with will have all of the same
>issues we have with php-doc blocks and existing libraries.
>
>I don't understand how such a feature would be useful to anybody?

As an addition, I don't think this feature should ADD new functionality to
those already present on DocBlocks. I just feel like docblocks are an ugly
hack for the lack of native annotations. Pasting from a previous discussion
in this same list, Rowan and I were discussing whether to add a native
docblock-annotation-retrieval feature or a native annotation syntax:

1) It 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 differently from comments,
that's not the common view on userland, nor is explained on the manuals.
There are no separate entries to explain docblocks, and no mention to them
on the "Comments" page. The Reflection method to retrieve DocBlocks is
"getDocCOMMENT", which suggests they are comment that do not affect runtime
behaviour.

We'd have to update the comments page to say "'/*' starts a comment, unless
if they're immediately followed by another asterisk ('/**'), in which case
it may or may not be a comment, depends on the following token". It's very
confusing.

3) To make this work within docblocks, we'd have to get rid of at least one
configuration setting (opcode.save_comments).

4) Dockblocks are stripped from obfuscators and transpilers, which are a
part of the ecosystem and do affect users, even if they are not first-class
citizens here.

Annotations in dockblocks are hard to understand because they they may or
may not be runtime-affecting annotations and there is no way to tell.

I hate this comparison with docblock annotations, because they are an UGLY
HACK. It works wonderfully, yes, but so do global variables, singletons and
what-not, and we are not using them anymore, are we? Adding this very same
feature that already exists in userland as a dedicated syntax would fix a
lot of issues, cited above. There is no need to evaluate logic inside
annotations, let them be value-objects, let it throw errors autoloading
said objects, and let's get this rolling.

Please, don't embargo this ONCE again. It's a very much needed feature, and
people want it! There have been innumerous discussions on reddit, and
almost everyone agrees annotations are a missing feature and
comment-annotations are an ugly hack for the lack of native syntax.

Please, make this happen.

2016-06-28 11:12 GMT-03:00 Marco Pivetta :

> Hi Rasmus,
>
> On 27 June 2016 at 20:37, Rasmus Schultz  wrote:
>
> > Tonight I started trying to write a proposal for even more simplified
> > annotations, e.g. something simple enough that it cannot result in
> > fatal errors. I eventually gave up, and here's why.
> >
> > Essentially, if you have to restrict yourself to things that cannot
> > under any circumstances error out, the only things you can use are
> > constant scalar values - even constant scalar expressions could not be
> > allowed, because even those could error when CONST_NAME or
> > Class::CONST_NAME aren't defined.
> >
> > So, in a nutshell, what you're saying (Richard) is that annotations
> > can only consist of scalar values, and possibly arrays of values? (and
> > I don't even see your gist doing that - it's just invoking closures,
> > as far as I can tell, and any of those could error, or not?)
> >
> > So, regardless of syntax, literally the only annotation data allowed
> > would be blatantly simple things like:
> >
> > ["max_length" => 20]
> >
> > ["data_type" => "int"]
> >
> > Or in other words, constant arrays, int, string, float and bool
> > values. Nothing else.
> >
> > Nothing can depend on any kind of external symbol (class names,
> > constants, etc.) since any such reference can cause an error.
> >
> > No static analysis or type-checking of any kind can ever be performed
> > - no assertions or declarations can be made about the shape or types
> > of metadata, at all.
> >
> > The problem is, that's simply not useful.
> >
>
> That's actually what doctrine/annotations has been for a while  tho, and a
> lot of people rely just on that.
> The data-structure is still enforced by a VO-style class (the annotation
> itself) in the library, though.
>
> It would still be very useful, in my opinion.
>
> Note that the existing annotation libs out there do indeed trigger
> autoloading for referenced class constants.
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>

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

[Pedro Cordeiro]

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 opinions
or discriminated someone in the workplace (or within the boundaries of the
project, github, mailing lists, forums, etc), the project mantainers have
no business snooping through their personal social accounts to see if they
are against gay marriage.

Also, 'offensive' is always subjective. On a more moderate example,
supporting Edward Snowden might be offensive to someone who lost a child in
a terrorist attack and that thinks the government has the right to protect
the people by using any means necessary.

2016-01-19 16:17 GMT-02:00 Arvids Godjuks :

> 2016-01-19 20:03 GMT+02:00 Arvids Godjuks :
>
> > Hello to everyone.
> >
> > The Draft states:
> >
> > "This Code of Conduct applies both within project spaces and in public
> > spaces when an individual is representing the project or its community."
> >
> > TL;DR: Just no.
> >
> > Long version:
> >
> > What is the definition of "representing project or it's community". If I
> > make a single commit that get's accepted to the project, and then I say
> > something 3 years down the line about the project (in this case PHP), do
> I
> > still represent the project or it's community? Or I have added to
> > conversations on this mailing list for years now, does that mean i'm a
> > contributor now and I'm responsible for anything I say about the project
> or
> > it's community going forward?
> > And what is PHP community? It's not like PHP community is a tight group -
> > it's huge, with tens of millions of people at least all over the world.
> >
> > This is especially a worry for me, because I run a PHP conference, and
> > people come to speak to it. I do not want to deal with people dictating
> me
> > "I want you to pull this person because his views on blah are bla bla bla
> > and that is unacceptable". I do not care about the persons views on any
> > subject, unless:
> > a). It breakes the laws of my country (hate speech, harassment, gender
> > discrimination and all that stuff that is actually covered by laws).
> > b). The person goes into issues, that are not the topic of the
> conference.
> > c). Behaves in a way, that is not acceptable in the society (personal
> > insults, unacceptable language, and so on).
> > And what if I actually agree with that person in my own views? And why
> > someone thinks he has the right to dictate what views are acceptable and
> > witch are not? (i'm not talking about issues, that are universally
> > unacceptable to talk about).
> >
> > Regarding c) - you should remember, that in different parts of the world
> > the social norms vary - from slightly to moderate between western
> cultures,
> > to quite a lot for asian/latin american/african/etc. . Every country is
> > different, especially those, that are quite far apart. That means that
> > people will be doing things, that are totally acceptable and are the norm
> > in their country, when they are preforming at the local conference, but
> > will probably trigger a storm somewhere else, and that may result in
> things
> > going horribly wrong.
> >
> > So, as far as my personal opinion goes, CoC has to apply only to project
> > spaces in full, and for the public spaces it has to have a clear
> > definition, when CoC applies. I really do not want to see situation like
> > they happened in other projects, when a person can be booted off the
> > project just because he does not support some trending new thing in
> social
> > areas (pick any social issue in recent 20 years), but is absolutely a
> model
> > member of the project. This is a tech project, not a social gathering to
> > impose social trends and rallying support for social issues.
> >
> > * Any personal opinions on any subject not directly related to the
> project
> > itself should be out of the scope of CoC. This has to be written in from
> > the start, otherwise people will find a way to exploit it to generate
> > controversy and drama on the subjects that are not related to the PHP
> > project.
> > * CoC should clearly state that it is designed only to handle the conduct
> > in project channels and official representation of the project. The
> > representation part should be defined.
> > * Any requests coming in on the issues, that are not directly related to
> > the PHP project itself, should be outright rejected. In case of abuse
> > (trying to re-open the issues) the access should be restricted if that's
> > technically possible.
> >
> > Otherwise, as history shows, the rules are abused sooner or later. And
> the
> > amount of controversy we have around PHP every minor and major release,
> > that's a given.
> >
> > Above written is a rough thought list on the 

Re: [PHP-DEV] Native Annotation Syntax

[Pedro Cordeiro]

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 differently from comments,
that's not the common view on userland, nor is explained on the manuals.
There are no separate entries to explain docblocks, and no mention to them
on the "Comments" page. The Reflection method to retrieve DocBlocks is
"getDocCOMMENT", which suggests they are comment that do not affect runtime
behaviour.

We'd have to update the comments page to say "'/*' starts a comment, unless
if they're immediately followed by another asterisk ('/**'), in which case
it may or may not be a comment, depends on the following token". It's very
confusing.

3) To make this work within docblocks, we'd have to get rid of at least one
configuration setting (opcode.save_comments).

4) You've suggested disregarding docblock stripping from transpilers and
obfuscators, because they are not first-class citizens, even though those
are part of the PHP ecosystem and affect users.

5) We'd have a harder time making decisions on syntax for docblocks,
because there are already multiple different implementations, and because
people will have a hard time agreeing on some points, like the one
guilherme made about the asterisks (*) or spaces being part of multiline
annotation or not.

Whereas none of these points are issues for a native syntax outside
docblocks, because it'd be a completely different feature that would reside
in new syntax, not in modification of current syntax.

2015-11-26 8:06 GMT-02:00 Rowan Collins :

> guilhermebla...@gmail.com wrote on 26/11/2015 01:13:
>
>> Ok, so I'll explain why it's not "the same way" as you imagine.
>>
>> I've heard this many times already so I'll save you keystrokes.
>> - "Sure, we can do that on docblocks"
>> - "Based on that, it doesn't need to be part of core and can safely be
>> implemented as a PECL extension"
>>
>>
> OK, as far as everything I was talking about, this is all rather a straw
> man, but perhaps that's just a miscommunication on my part, so let me clear
> that up:
>
> I have never suggested, and would not support a suggestion, that this be
> implemented as an extension. I can absolutely see the advantage to having a
> first-class syntax, baked into the main parser.
>
> With that out of the way, we are back to the main point I was trying to
> make which is that that syntax could, if we wanted, live inside the context
> of /** */ blocks, which are already treated differently from comments. The
> parsing problems within that context are very similar to the parsing
> problems in any other context (again, assuming that this is being
> implemented directly in the core parser, not in any kind of extension).
>
> So, the pros and cons of that are not to do with the parsing but to do
> with:
> - potential compatibility with existing code, which may be tricky as there
> is no standard to base the feature on
> - the ability to polyfill code in older PHP versions, which is useful but
> not something we have aimed for with previous features
> - on the other side, the perception that docblocks are "just comments",
> which would be hard to dispel even if we renamed them "metadata blocks"
>
> Anyway, I apologise for drawing out this part of the discussion for so
> long. I actually think it's just one of many decisions that needs making
> before this feature can be attempted, probably starting with just what an
> annotation consists of - is it a label with some text attached? a resolved
> class name with parsed PHP code passed to its constructor (some people have
> mentioned arrays and heredocs as parameters to annotations)? somewhere
> between the two?
>
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Native Annotation Syntax

[Pedro Cordeiro]

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 be willing to create a new RFC draft for a native annotation
syntax, targeted at 7.1, this time explaining the reasons NOT to do this in
docblocks nor in a seperate extension, so the discussion won't get
sidetracked again. I'd need some help with the patches, though, since I
don't have any experience with the internals.

There is still the issue of complexity added to the engine, which we could
discuss. I'd like to hear more from a long-term contributor about that, if
it's possible. Were there any performance implications on the previously
submitted patch?

Thank you everyone for the great discussion.

Re: [PHP-DEV] Native Annotation Syntax

[Pedro Cordeiro]

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 15:11 GMT-02:00 Levi Morrison :

> On Thu, Nov 26, 2015 at 9:57 AM, Rowan Collins 
> wrote:
> > guilhermebla...@gmail.com wrote on 26/11/2015 16:05:
> >>
> >> Ok then. I'll pretend that lack of interest didn't happen many other
> >> situations (like http://marc.info/?t=14460876781) and move on.
> >
> >
> > It's possible that a lot of the core devs are still concentrating on
> getting
> > the changes in 7.0 bedded in, and have more time to discuss features for
> 7.1
> > in a month or two.
>
> At least a few are working on features of their own.
>
> I am curious – a quick scan of this thread didn't seem to actually
> propose anything new. It's just discussion about same RFC that was
> already rejected. Correct?
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Native Annotation Syntax

[Pedro Cordeiro]

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 they are, PHPStorm will
not hint/autocomplete, nor will eclipse/netbeans) would be
Symfony2/Doctrine2. There are tons of other tools that with custom
annotations (JMSSerializer as an example) that do not have any support at
all.

This argument is so flawed that you didn't consider that there are many
parsers with many different syntaxes (
https://github.com/jan-swiecki/php-simple-annotations,
https://github.com/nette/neon) and that ANY implementation, be it through
docblocks or with a native syntax would require a rewrite anyway for many
projects if those tools want to support the new native feature.

Also, doing it through an extension is a nice way to delay adoption,
because shared hosts rarely give the option to install new extensions.

I don't have a vote here, but if I had, I'd strongly oppose any
docblock-based implementation.

Re: [PHP-DEV] Native Annotation Syntax

[Pedro Cordeiro]

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 implementations.

Docblocks are Documentation Blocks, which is meant for documentation only.

Mixing documentation (@param) with runtime stuff (@manyToMany) is
counter-intuitive and makes the ecosystem harder to learn.

It's also weird that removing comment blocks break an app.

2015-11-25 14:47 GMT-02:00 Rowan Collins :

> Larry Garfield wrote on 25/11/2015 16:42:
>
>> However, doing so would make static checking more difficult; If
>> annotations become a language-native feature, they should be a first-class
>> citizen to make it easier for IDEs to handle.
>>
>
> Could you explain why docblocks are harder to parse than text outside
> docblocks? As far as I know, IDEs *already* parse docblocks, e.g. using
> @param and @return for type analysis, so I don't really see why
> generalising that would be a big problem.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Native Annotation Syntax

[Pedro Cordeiro]

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 
> wrote:
>
> > Larry Garfield wrote on 25/11/2015 17:39:
> >
> >> On 11/25/15 11:00 AM, Rowan Collins wrote:
> >>
> >>> I don't feel that strongly in favour of docblocks, but I don't think
> the
> >>> reasons given against are particularly strong.
> >>>
> >>> Regards,
> >>>
> >>
> >> If you don't feel strongly in favor of them, why are you trying to make
> a
> >> case for them so strongly?  Just for kicks?  We don't need a "devil's
> >> advocate" at this point in the discussion...
> >>
> >>
> > Hi Larry,
> >
> > I don't *feel* strongly in favour or against them, but can see advantages
> > and disadvantages on both sides. Feeling strongly is not the same as
> having
> > a strong argument for your point of view, so just because some people
> have
> > expressed strong opinions against, I don't see why I shouldn't challenge
> > their reasoning, even if that does mean playing devil's advocate.
> >
> > Which is better: basing the decision on the gut feeling of a handful of
> > people who happen to be here now, or basing it on sound reasoning after
> > thinking through the implications?
> >
> > Regards,
> > --
> > Rowan Collins
> > [IMSoP]
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
>
> --
> Guilherme Blanco
> MSN: guilhermebla...@hotmail.com
> GTalk: guilhermeblanco
> Toronto - ON/Canada
>

Re: [PHP-DEV] Native Annotation Syntax

[Pedro Cordeiro]

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
project-specific plugins, and adds this odd notion that removing some
comment blocks might break an app (which is just awful).

@beberlei, I had searched through the archives already and couldn't find
the vote. I found the discussion (in which many people advocated for
docblock annotations), but didn't find the vote.

I feel like this is a major feature that's missing, and people are using it
in a suboptimal way (docblocks), so I thought I'd reopen the discussion and
see if someone more familiar with the internals feels like implementing it
(I don't feel confident enough since I've never tried messing with into the
internals).

2015-11-24 22:31 GMT-02:00 Sara Golemon :

> On Tue, Nov 24, 2015 at 11:05 AM, Rowan Collins 
> wrote:
> > At first sight, these seem like details which could be tweaked later, but
> > they make a difference to what syntax to standardise: is the annotation
> name
> > just a string, or a valid class name? is the value of the annotation
> just a
> > string, or a parseable PHP expression? is it more useful to use the de
> facto
> > existing syntax in DocBlocks, or to add a new keyword or operator? etc
> >
> If we're going to use something in the docblock, then I wouldn't want
> it parsed on compilation, but rather have it be an on-demand parse
> while reflecting.  The reason being that there are plenty of
> docblock'd PHP libraries out there using invalid annotations because
> they're not running it through tools to tell them what they got wrong.
> Waiting till they've actually tried to examine it through reflection
> lets us throw an exception on code that cares about it rather than
> preventing code which ignores reflection from running.
>
> I, for one, am a fan of Java style annotations which allow a string
> name plus optional metadata.
>
> @@foo
> class Bar {
>   @@Baz("something", 123, [ 'a', 'b', ''c'])
>   public function qux() { ... }
> }
>
> Though the formality of having to define the annotation as an
> interface is a bit overkill for PHP, the same rules Hack uses would be
> clear and simple enough:
>
> <>
> class Bar {
>   <>
>   public function qux() { ... }
> }
>
> And no, I'm not picky about the parser symbol used...  In fact,
> allowing an optional '//' prefix to annotations might be nice for
> compatibility.
>
> -Sara
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] Native Annotation Syntax

[Pedro Cordeiro]

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
retrieving annotation from DocBlocks through reflection is 'inactive', with
no further explanation.

I'd really like to see native annotation support for PHP that doesn't live
in comments.

Is there a reason those RFCs were dropped, or was it just lack of interest?

- Pedro.

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

[Pedro Cordeiro]

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 away from
what PHP already does (returning null when a return is absent) and still
being perfectly in line with when people access values from undefined
things (like an uninitiated variable, which throws E_NOTICE and returns
null).

2015-10-29 10:44 GMT-02:00 Dan Ackroyd :

> Hi Internals,
>
> Stanislav Malyshev wrote:
> > every PHP function actually returns
> > something (at least null). So this type would not actually be right and
> > would not reflect what actually is happening.
>
> Well obviously we would need to have a followup RFC to make void
> functions not have a usable return value! /s
>
> I drafted this email a week ago and didn't send it as I though it was
> too snarky to be a useful thing to add to the conversation, but it
> seems that it has come up:
>
> François_Laupretre wrote:
> > Is it too late to add a note in the RFC, listing the possibility, in the
> > future, to forbid using the result of void functions in expressions.
>
> This is an idea that this RFC obviously leads to, but one that is very bad.
>
> Being able to call a function dynamically and not need to determine
> whether it is 'void' return type eliminates a whole class of errors
> that can occur when calling code dynamically.
>
> function timeFoo(callable $fn) {
> startTime();
> $result = $fn();
> endTime();
>
> return $result;
> }
>
> This can be done without any inspection on what the return type of
> `$fn` is, and is one of the things that PHP got right.
>
> And yes, if we don't make that change, using the pseudo-type of 'void'
> instead of 'null' is going to be an instant source of PHPSadness.
>
> Q: This function has a 'void' return type but it's actually returning null?
> A: Yes.
> Q: Shouldn't it have a 'null' return type?
> A: Apparently they chose to make the language follow the manual rather
> than make the manual follow the language.
> Q: ...Is it too early to start drinking yet?
>
> Tring to 'clean this up' by preventing a void function being used as
> an expression, is an example of making the program follow the PHP
> manual's convention, rather than making the manual document what the
> engine does.
>
> Levi Morrison wrote:
> > This is one reason I am in favor of `null`
> > instead of `void`. Void does not accurately portray the semantics in
> > my opinion. If the return type was null instead of void there would be
> > no issue. Sure, the return value would be null, but partialLeft
> > doesn't care – it just passes whatever the result was.
>
> I think this is an important point, and so to try and expand on this a
> bit; if you have a function that does not return a value or has a
> void/null return type, then this code:
>
> logResult(foo());
>
> is valid.
>
> The person who wrote the function 'foo' might not anticipate that the
> function would be used in that way but that is valid code. It is only
> when you actually try to use the value as anything other than null
> that it becomes a problem i.e.
>
> function findUserbyId(int $userId) {...}
> findUserbyId(foo());
>
> it's when you pass the null value to function that needs a non-null
> value that the error occurs.
>
> Although alerting someone that they are using a null value where they
> actually need another type is a useful thing, we do not need another
> type (or pseudo-type) to do this. We should add null as a return type
> rather than void as null:
>
> * accurately describes what is happening in the engine, instead of
> being an instant source of confusion.
> * is compatible with the proposed 'nullable return types' and/or
> 'union types', void isn't.
> * avoids adding a new pseudo-type just for a single use case.
>
> cheers
> Dan
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

[Pedro Cordeiro]

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
'nothing' ($b), and got NULL with an E_NOTICE being thrown.

function myFunc() : void { ... }
$a = myFunc();

I see no reason why this should silently assign NULL to $a, *specially* with
"return null;" being explicitly forbidden.

My point is: we already use an implicit NULL return on functions with
missing return values (or with "return ;"), but now we're explicitly
prohibiting even a NULL return. The behaviour should be consistent (NULL
should be accessed, as for all undefined things), with an E_NOTICE.

function myFunc() { return ; }
$a = myFunc();

Should assign NULL to $a and *not* throw an E_NOTICE (this is the current
status), because a return type was not forbidden with the keyword 'void'.

2015-10-15 13:00 GMT-03:00 Rowan Collins :

> Andrea Faulds wrote on 15/10/2015 16:32:
>
>> Hmm, this is an interesting case you've pointed out. Being able to do
>> `return some_other_void_function();` is something I've desired in other
>> languages.
>>
>> But what if that void function you're calling later adds a return value?
>> Now the calling function is returning a value other than null, violating
>> its type hint and producing a runtime error.
>>
>
> Well, fundamentally, this is true of anything short of full type-checking.
> The type safety below is self-evident:
>
> function foo(): int { return 42; }
> function wrapped_foo(): int { return foo(); }
>
> But foo() could later be changed to this:
>
> function foo(): string { return 'The Answer'; }
>
> The wrapped_foo() typehint is now broken. That's not really any different
> from foo() starting off as void/returns-null and adding a return value.
>
> In both cases, a static analyser could detect the discrepancy, but the
> Zend Engine will not, until the function is executed.
>
>
> It's a shame there's no "tail call this other function and discard its
>> result" construct.
>>
>
> Yeah, I guess what you really want is for a void function to be able to
> "goto foo();"
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

[Pedro Cordeiro]

>
> this would make the "void" keyword feel more meaningful.


I, too, had issues trying to understand what "void" was bringing to the
table. IMHO, it should warn people thinking some specific function/method
returns a value when it doesn't, not protect against some dev forgetting
the function he's writing should not return something.

IMHO, it's far more important to warn "Hey, this function returns NOTHING,
don't try to use its value because it doesn't exist!" then it is to warn
"Hey, this function can't return anything, stop trying to return things!".

Throwing an E_NOTICE when accessing a void return value would make perfect
sense, as the compiler would strict check that the function author defined
a no-return and indeed returned nothing and would also warn whoever was
calling the function that it doesn't return anything.

> We could do this, but I do wonder if it might cause a lot of E_NOTICEs to
pop up for existing code, assuming we applied this to built-in PHP
functions.

My proposal is to only throw an E_NOTICE when accessing a return value from
a function that is explicitly marked with "void". A function with no return
("return ;") but with no ": void" on the signature would not necessarily
throw an E_NOTICE.

function myFunc() { return ; }
$a = myFunc(); //NULL should be assigned to $a silently, like it is today.
function myOtherFunc() : void { return ; }
$b = myOtherFunc(); //NULL should 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, and so far, I think the consistent thing should be
>> to
>> get NULL, while throwing an E_NOTICE.
>>
>
> We could do this, but I do wonder if it might cause a lot of E_NOTICEs to
> pop up for existing code, assuming we applied this to built-in PHP
> functions.
>
> I'm not sure.
>
> Thanks.
> --
> Andrea Faulds
> http://ajf.me/
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

[Pedro Cordeiro]

> 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 standard or clean reading.

If someone chooses to lose their precious time implementing this, it would
actually give some people a new feature (clean diffs while keeping PSR2
compliance) without taking anything away from people who oppose this. This
is not objectively bad, it just adds an option to the pool, which I think
is good.

I see no reason to allocate resources to make this happen, but if someone
does allocate their personal time into coding this, I wouldn't oppose a
merge.

But again, I have no vote.

2015-10-15 16:16 GMT-03:00 Ryan Pallas :

> On Thu, Oct 15, 2015 at 11:14 AM, Sara Golemon  wrote:
>
> > On Wed, Oct 14, 2015 at 11:59 PM, Björn Larsson
> >  wrote:
> > > Given the reason against this RFC in the thread it would be interesting
> > > to know why HHVM decided to implement it?
> > >
> >
> > Happy to answer, but I need to state a couple things first:
> > * I don't really care if this change lands.  I'd kinda like it, but
> > it's not solving a massive problem for me.
> > * There aren't any compelling reasons against this.  The only reason
> > given of any note that I've seen is: "There are no compelling reasons
> > in favor of it."  And I'll agree with that.  Like I just said, it's
> > not solving any major problems, and it's not going to cause any major
> > problems.  It's just a tiny, vanishingly insignificant piece of
> > syntactic sugar which disappears before we even get to the AST.
> >
> > So again, could scarcely care less, so don't expect me to champion
> > either side, but you asked "why", so here it is: It makes code reviews
> > marginally less ugly.
> >
> > That's it.  It's a tiny problem to solve, and likely saves less than
> > 100ms during diff reviews, but it's a solution to a problem.
> >
> > Yes, it's a problem which countless developers live with to no
> > significant negative consequence.  Solo developers and small shops
> > won't care about this since they tend to not bother with code reviews.
> > FB has enough engineers working on its very large codebase though,
> > that nobody has it all paged in, so code reviews are mandatory, and if
> > we can spend five minutes of effort to loosen the parser rules in
> > exchange for saving 1/10th of a second on every diff review that
> > extends/shrinks a function call/signature with no overhead, then of
> > course we would.  That's a fair exchange.
> >
> > Apologies if you were hoping for a compelling reason.
> >
> > But its an entirely stylistic choice to use trailing commas for cleaner
> diffs. You could also use leading  commas as well. If you made that a
> coding standard for the organization, you would not have needed to
> implement trailing am I right?
>
> function foo(
>$bar
>   ,$baz
>   ,$boo
> ) { ... }
>
> too_many_args(
>$this->id
>   ,'some constant string'
>   , 123
> );
>
> Wouldn't this give the same benefit as trailing commas when it comes to
> adding removing arguments - a single line diff?
>