Re: [PHP-DEV] Re: [RFC] [VOTE] Short Closures

[Sara Golemon]

On Thu, Sep 24, 2015 at 12:10 AM, Stanislav Malyshev
 wrote:
>> As a PHP developer, I agree with the possible confusion between `->` and
>> `~>`.
>> `==>` is a better choice IMHO, for its similarity with Hacklang syntax, as
>> said previously.
>
> I'm getting a feeling the RFC could be more successful if syntax was
> made a choice between ~> and ==> as a voting option.
>
Agreed.  Let's leave the bike-shedding over operators to its own
topic.  The binding rules are much more consequential and deserving of
discussion.

-Sara

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] [VOTE] Short Closures

[Julien BENOIT]

Hi,

As a PHP developer, I agree with the possible confusion between `->` and
`~>`.
`==>` is a better choice IMHO, for its similarity with Hacklang syntax, as
said previously.

Thanks.

*Julien BENOIT*
*PHP & JS developer @GuestToGuest *
Paris, FR.
blog.julienbenoit.net
  



2015-09-24 8:39 GMT+02:00 Marco Pivetta :

> Changed my vote to "no" after thinking further into it:
>
>  - I don't like the usage of the tilde: `->` and `~>` are too similar and
> easily confused
>  - Using `==>` would align PHP further to hacklang, which is a plus
>  - I'm still conflicted on automatically importing all of the scope into
> the closure: while it is working for functional languages, that's where
> most of the headaches come from in languages such as javascript.
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
> On 24 September 2015 at 14:27, Pierre Joye  wrote:
>
> > On Sep 22, 2015 10:16 PM, "Andrea Faulds"  wrote:
> > >
> >
> > > I am unhappy with the ~> syntax choice. As I've mentioned before, it's
> > hard to type for many people, it looks too much like ->, and it's
> > unnecessarily different from Hack's ==>, of which this RFC would
> otherwise
> > be proposing a strict subset.
> > >
> > > So, I am voting against.
> >
> > Same reason here.
> >
> > Thanks,
> > Pierre
> >
>

Re: [PHP-DEV] Re: [RFC] [VOTE] Short Closures

[Björn Larsson]

Den 2015-09-24 kl. 09:10, skrev Stanislav Malyshev:

Hi!


As a PHP developer, I agree with the possible confusion between `->` and
`~>`.
`==>` is a better choice IMHO, for its similarity with Hacklang syntax, as
said previously.

I'm getting a feeling the RFC could be more successful if syntax was
made a choice between ~> and ==> as a voting option.

How does one then address that this RFC only covers a subset of
Hacklang functionality when having the same operator?

--

//Björn Larsson


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] [VOTE] Short Closures

[Rowan Collins]

Lester Caine wrote on 24/09/2015 08:06:

So is PHP heading
down the path of a compiled language even if that is hidden in some
automatic cache or is it still mainly an interpreted script?


PHP already is a compiled language; it just has a highly dynamic runtime 
engine (which is at times a blessing, and at times a curse).



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] [VOTE] Short Closures

[Stanislav Malyshev]

Hi!

> As a PHP developer, I agree with the possible confusion between `->` and
> `~>`.
> `==>` is a better choice IMHO, for its similarity with Hacklang syntax, as
> said previously.

I'm getting a feeling the RFC could be more successful if syntax was
made a choice between ~> and ==> as a voting option.
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] [VOTE] Short Closures

[Pierre Joye]

On Sep 24, 2015 2:11 PM, "Stanislav Malyshev"  wrote:
>
> Hi!
>
> > As a PHP developer, I agree with the possible confusion between `->` and
> > `~>`.
> > `==>` is a better choice IMHO, for its similarity with Hacklang syntax,
as
> > said previously.
>
> I'm getting a feeling the RFC could be more successful if syntax was
> made a choice between ~> and ==> as a voting option.

Yes, given we do not have issues with the use (which seems to be cleared
now)

> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] Re: [RFC] [VOTE] Short Closures

[Marco Pivetta]

Changed my vote to "no" after thinking further into it:

 - I don't like the usage of the tilde: `->` and `~>` are too similar and
easily confused
 - Using `==>` would align PHP further to hacklang, which is a plus
 - I'm still conflicted on automatically importing all of the scope into
the closure: while it is working for functional languages, that's where
most of the headaches come from in languages such as javascript.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

On 24 September 2015 at 14:27, Pierre Joye  wrote:

> On Sep 22, 2015 10:16 PM, "Andrea Faulds"  wrote:
> >
>
> > I am unhappy with the ~> syntax choice. As I've mentioned before, it's
> hard to type for many people, it looks too much like ->, and it's
> unnecessarily different from Hack's ==>, of which this RFC would otherwise
> be proposing a strict subset.
> >
> > So, I am voting against.
>
> Same reason here.
>
> Thanks,
> Pierre
>

Re: [PHP-DEV] Re: [RFC] [VOTE] Short Closures

[Pierre Joye]

On Sep 22, 2015 10:16 PM, "Andrea Faulds"  wrote:
>

> I am unhappy with the ~> syntax choice. As I've mentioned before, it's
hard to type for many people, it looks too much like ->, and it's
unnecessarily different from Hack's ==>, of which this RFC would otherwise
be proposing a strict subset.
>
> So, I am voting against.

Same reason here.

Thanks,
Pierre

Re: [PHP-DEV] Re: [RFC] [VOTE] Short Closures

[Lester Caine]

On 24/09/15 07:39, Marco Pivetta wrote:
>  - I'm still conflicted on automatically importing all of the scope into
> the closure: while it is working for functional languages, that's where
> most of the headaches come from in languages such as javascript.

Isn't this the crux of some decisions? Once one adopts compiling as an
essential step a number of the rules can be changed. So is PHP heading
down the path of a compiled language even if that is hidden in some
automatic cache or is it still mainly an interpreted script? Lots of
things are easier if you apply optimization in the compile stage but
that then blocks many of the dynamic actions which PHP *IS* so good at.
The sort of thing that allows thousands of pages of content to be stored
in a database without some of the straight jacket that some people seem
to think is essential these days?

If I'd wanted a fully compiled system I'd have stayed with C/C++ all
those years ago ... as I keep harping on PHPs dynamic nature is it's
strength?

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] [VOTE] Short Closures

[Jordi Boggiano]

On 24/09/2015 07:39, Marco Pivetta wrote:

  - I'm still conflicted on automatically importing all of the scope into
the closure: while it is working for functional languages, that's where
most of the headaches come from in languages such as javascript.


The automatic import IMO isn't as much an issue as in JS, because it 
imports by value and not by reference as is done in JS. If you do $foo = 
'bar'; in your closure and suddenly someone in the outer scope defines 
$foo as well, you aren't going to overwrite that outer scope value. 
Therefore the risks for interferences are reduced quite a bit.


Cheers

--
Jordi Boggiano
@seldaek - http://seld.be

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] [VOTE] Short Closures

[Rowan Collins]

On 24 September 2015 19:21:20 BST, Stanislav Malyshev  
wrote:
>> How does one then address that this RFC only covers a subset of
>> Hacklang functionality when having the same operator?
>
>Why one should address it? PHP is a different language, and we are
>under
>no obligation to completely match functionality of any other language.

Well, if the only reason for selecting that operator was to match Hack, it 
would be odd to take its meaning in a different direction.

Other reasons have been given, though, and the functionality is similar enough, 
so I don't think it's a big problem myself, but I can see the logic of 
questioning it.

Regards,
-- 
Rowan Collins
[IMSoP]


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] [VOTE] Short Closures

[Stanislav Malyshev]

Hi!

> How does one then address that this RFC only covers a subset of
> Hacklang functionality when having the same operator?

Why one should address it? PHP is a different language, and we are under
no obligation to completely match functionality of any other language.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] [VOTE] Short Closures

[Björn Larsson]

Den 2015-09-24 kl. 20:21, skrev Stanislav Malyshev:

Hi!


How does one then address that this RFC only covers a subset of
Hacklang functionality when having the same operator?

Why one should address it? PHP is a different language, and we are under
no obligation to completely match functionality of any other language.

In principal I agree, but by using the same operator one sets an
end-user expectation that the functionality is close to the same.

Regards //Björn Larsson


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] [VOTE] Short Closures

[Björn Larsson]

Den 2015-09-22 kl. 17:16, skrev Andrea Faulds:

Hi Bob,

Bob Weinand wrote:

Hey,

Thanks for all your feedback in the discussion thread!

So, before I start the vote, just two quick notes:
I've added two notes about the statement syntax and the single 
variable use.
Though a few people complained, I'm not switching to the ==> 
operator, as I noticed many people expected typehints to work (they 
don't due to parser limitations) when they compared to Hack's short 
Closures. It also allows us to differ syntax-wise [e.g. for 
typehints] from Hack without causing any confusion later. Which 
should be the smartest choice: Avoid conflicts. (If anyone strongly 
feels against that, he may vote no, but I would like to not bikeshed 
that in this Vote thread, but leave it free for eventual actual issues.)


Now, the link to the RFC about Short Closures:
https://wiki.php.net/rfc/short_closures
or straight ahead to the vote:
https://wiki.php.net/rfc/short_closures#vote


I am unhappy with the ~> syntax choice. As I've mentioned before, it's 
hard to type for many people, it looks too much like ->, and it's 
unnecessarily different from Hack's ==>, of which this RFC would 
otherwise be proposing a strict subset.


So, I am voting against.

Thanks.


One a side-note using a nordic keyboard-layout one needs to push
altgr+~+space to get the ~ sign. To get the $ sign one needs to push
altgr+$, but $ is on the left of keyboard while ~ is on the right. So in
my eyes the difficulty is similar. I find it more annoying though with
the $ sign.

Regards //Björn


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] [VOTE] Short Closures

[Stig Bakken]

On Sep 24, 2015 09:07, "Lester Caine"  wrote:
>
> On 24/09/15 07:39, Marco Pivetta wrote:
> >  - I'm still conflicted on automatically importing all of the scope into
> > the closure: while it is working for functional languages, that's where
> > most of the headaches come from in languages such as javascript.
>
> Isn't this the crux of some decisions? Once one adopts compiling as an
> essential step a number of the rules can be changed. So is PHP heading
> down the path of a compiled language even if that is hidden in some
> automatic cache or is it still mainly an interpreted script? Lots of
> things are easier if you apply optimization in the compile stage but
> that then blocks many of the dynamic actions which PHP *IS* so good at.
> The sort of thing that allows thousands of pages of content to be stored
> in a database without some of the straight jacket that some people seem
> to think is essential these days?
>
> If I'd wanted a fully compiled system I'd have stayed with C/C++ all
> those years ago ... as I keep harping on PHPs dynamic nature is it's
> strength?
>

I assume you mean strongly typed, because PHP has had a compiler for about
18 years ;)

The main restriction on PHP's compiler is really that it has to be
reasonably fast, it can't afford to do all the clever and very expensive
optimizations that for example gcc does. Maybe less so today when we can
expect everyone to have an op cache, but still.

Auto-importing variables would not be expensive, or even noticeable. But it
breaks completely from PHP's model of always being explicit about taking
symbols from another scope (globals). This is a property on which PHP
differs from other languages such as JS, Ruby or Groovy, which have similar
constructs. Is it OK to introduce an exception to that only for the sake of
having (an admittedly handy) short syntax for closures?

It's one of these "you want it, but it's not good for you" predicaments. My
vote will be no, unfortunately.

- Stig

Re: [PHP-DEV] Re: [RFC] [VOTE] Short Closures

[Anthony Ferrara]

Stas,

On Thu, Sep 24, 2015 at 2:21 PM, Stanislav Malyshev  wrote:
> Hi!
>
>> How does one then address that this RFC only covers a subset of
>> Hacklang functionality when having the same operator?
>
> Why one should address it? PHP is a different language, and we are under
> no obligation to completely match functionality of any other language.

Correct. We are under no obligation. But, it would be us playing
friendly neighbor and responsible community citizen if we didn't
re-use syntax in a different way. Remember, Hack isn't some arbitrary
different language, it's one that exists in the PHP ecosystem. We are
under no obligation to play nicely with them, but wouldn't it be nice
if we did anyway?

And part of that playing nice would be not re-using syntax in
different ways (that goes in both directions). Since that only will
make everyone's life more difficult.

Anthony

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php