Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Zeev Suraski]

On Wed, Aug 14, 2019 at 6:14 PM Derick Rethans  wrote:

> Hi,
>
> In the last week(s) there has been a lot of chat about Zeev's P++ idea.
> Before we end up spending this project's time and energy to explore this
> idea further, I thought it'd be wise to see if there is enough animo for
> this. Hence, I've created a document in the wiki as a poll:
>

All,

Using a humoristic tone, I'm happy that finally internals@ is so unified.
I almost get the feeling that you may not like the idea...

On a more serious note, I'll keep the feedback on the validity of this vote
in just about every aspect (process, jurisdiction, anything really) to
myself, and say just two things:

- The P++ idea makes absolutely no sense in vacuum.  The reception around
this idea implied a decision between 'one big happy family' and 'a split'.
Since at this stage these are the perceived choices - I'd vote against it
too (which I just did, why not).  However, I believe it's a false choice.

- It will absolutely make sense to discuss it when it'll start becoming
clearer to everyone that 'one big happy family' is really not an option.
We'd be choosing how to soft split the family - granularly (2^n dialects),
into many editions (n dialects), or into two separate dialects with clearer
mandates (2 dialects).  I get it that it's intangible for many of us
(myself included, to a degree), which is why this idea is perceived as the
'evil splitter' for everyone to unite and rally against.  Maybe I'm wrong,
and the changes/features that I think are about to make it into PHP aren't
going to require any sort of split.  If that's the case - it's indeed a
horrible idea.  We'd only be able to see that a but further down the road.
It's definitely too early to spend that level of energy on it at this stage
- but at the same time, it will definitely make sense to explore it if &
when the reality I think we're going to be facing would begin to unfold.

I will not be responding to any further emails on this thread;  I'll
happily reply to private messages though.

Thanks,

Zeev

Re: [PHP-DEV] Deprecate PHP's short open tags, again

[Robert Korulczyk]

> Good for you! Come take a stab at my legacy project. It's horrendous. We have 
> some files where using PhpStorm's automatic formatting actually caused
> stuff to break. So, you can see why I might be a little reticent to depend on 
> an automated tool to change my php tags. I'll let you start with a 12k+
> line file of spaghetti code. This file contains a lot of functions (not OO) 
> used across the legacy parts of the application. As such, it's included at
> the top of pretty much every PHP page. So, make sure you don't leave a typo, 
> because it'll break the entire application! 

I know how painful could be maintaining legacy code, but did you tried to run 
php-cs-fixer against this 12k+ file with PHP-spaghetti and report some
actual issues? You're spending time theorizing how automated tool can break 
your legacy code, but it would be far more productive if you spend it on
actual tests - this would give us very valuable insights how serious this 
problem is. Right now these are nothing more than *speculations* based on
usage of *completely different tool* for *completely different task*. Please, 
don't treat it as some hard argument.

> While you are at it, you can explain to my executive team (I don't work for a 
> software company) why it's worth putting in the time to modify all
> these "don't touch unless it's an emergency" legacy files to upgrade PHP when 
> the current version seems to be working fine from their perspective.

Sure. It would be something like: "Hey, it's *emergency*!" ;)

> That's another difference I've seen from the two sides of the argument. Those 
> in favor of removing them usually say things like "It doesn't seem like
> a big deal to me" or "I converted a project and it was really easy" or 
> "People shouldn't be using short tags anyway, so who cares." While those
> against removing them usually say things like "I can see how this could be a 
> huge problem for a large number of users" or "This could definitely block
> a lot of people from upgrading in a timely manner." 

This is one side of the coin. I'll show you another: I gave a real-world 
example that short open tag could lead to serious fuckup and be undetected
for quite a long time. I also gave an example of how easy is to accidentally 
introduce short open tags in your code. There are other people who also
treats short open tags as dangerous feature and security issue. Despite this, I 
can read multiple times that "short open tags are no-issue" or "there
is no gain in removing short open tags". In counterargument for this RFC you 
can read that "Deprecating short tags, as illustrated in this
counterargument, brings us *virtually no value at all*.".
There is no difference between both "camps" - both are focusing on their 
perspective and their arguments, while underestimating problems and arguments
of other "camp". For you existence of short open tags is minor issue, for me 
migrating to `http://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate PHP's short open tags, again

[Claude Pache]

> Le 14 août 2019 à 19:01, Olumide Samson  a écrit :
> 
> This was exactly my reason for participating in this discussion, if such
> simple BC break encounters fierce and lengthy-weighted resistance, I'm not
> sure there will ever be a BC break, only additions without a necessary
> cleanup.
> 
> That's just like, there's a precedent to resist all kinds of BC break
> simply because there's no positive impact on the change.

No, BC breaks and cleanups have been regularly implemented in the past, and 
that will continue. Two recent examples among several others:

https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase 

https://wiki.php.net/rfc/ternary_associativity 


About short-open tags. Many people thought that this particular BC break or 
cleanup was not useful enough. That’s all.

—Claude

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Olumide Samson]

I would say, PHP needs a direction(where're we headed?) than having a split
language.

Seriously, the core team have *tons of kudos* from the outside world(even
outside of PHP) and i think something called for those serious
implementation and i believe everyone(or simply put, the majority) one day
would see the need to make many improvements where necessary.

P++(Or other name it gets) is another project.

On Wed, Aug 14, 2019 at 4:58 PM Chase Peeler  wrote:

> On Wed, Aug 14, 2019 at 11:27 AM Sara Golemon  wrote:
>
> > On Wed, Aug 14, 2019 at 10:14 AM Derick Rethans  wrote:
> >
> > > https://wiki.php.net/rfc/p-plus-plus
> > >
> > > To follow up my no vote; What I'm against is splitting the language on
> > hard boundaries that never disappear, only widen. I'm also a 'No' on
> > Editions, but slightly less of a 'No', and possibly a 'Yes', if those
> > editions are clearly intended to fade over time.
> >
> > -Sara
> >
> I'd vote "No" if I had a vote. I appreciate Zeev proposing the idea. I've
> been as vocal as he has on the short tag issue, and generally fall into the
> "avoid BC unless there are overwhelming positives" camp. Maybe I don't have
> the complete picture since I don't actually do core development, but I have
> been a professional PHP developer for 14 years (Thursday is my 14th
> anniversary) and I've been using it for fun/school work for 20 years. From
> what I've seen, there isn't near as much contention on BC breaks in general
> as a solution like this would require in order to be justified. As someone
> mentioned in another thread, the majority of the features discussed (union
> types, annotations, enums, etc.) don't require BC breaks at all. Among
> things that do require them (both new features and clean up of older
> features), I see that most people, myself included, willing to accept them
> once they have passed.
>
> I definitely think it's possible to more PHP forward with lots of new
> features, and even cleaning up some old and obsolete parts, without moving
> too far in either extreme in terms of BC breaks. I also think that
> internals has done a pretty good job of that up to this point, and have no
> doubt they will continue to do so.
>
> I don't know if it was just a coincidence in timing, but it feels to me
> like this proposal was spurred, at least in part, by the discussions over
> short tags. If so, I definitely think that it is an overreaction. I also
> think the discussions on short tags show why even taking this proposed path
> wouldn't solve anything in the long run. The discussion over short tags
> have got pretty heated at times, but it seems to me that it is mainly
> because both sides are just repeating their talking points without
> discussing or answering the points made by the other side. I think that is
> partly due to the discussion medium, and partly due to the diversity of the
> participants. Without immediate feedback in a manner you expect, it's hard
> to tell if the point you just typed out over 5 paragraphs actually made
> sense to others that will read it. Bottom line, though, is that there will
> be contentious debates about topics no matter what. You might be able to
> avoid the debate on whether or not to require strict typing in P++, but
> you've still got to decide on which types you're going to support. Strict
> typing might never again need to be discussed in legacy PHP, but, there
> will always be discussions about some of the more controversial ways that
> types are juggled.
>
> There might be a time in the future where I do feel like a proposal like
> this is justified or even needed. I just don't feel we are at that point
> right now, nor do I think we are headed towards it.
>
> --
> Chase Peeler
> chasepee...@gmail.com
>

Re: [PHP-DEV] Deprecate PHP's short open tags, again

[Olumide Samson]

On Wed, Aug 14, 2019, 5:23 PM Robert Korulczyk  wrote:

> > While possibly a bit hyperbolic, most of the arguments basically come
> off that way to me as well. I've definitely viewed most of what you've said
> in
> > that manner.
>
> I guess we're in some kind of limbo where half of the people do not
> consider problems which short open tags create as serious, and other half
> does not
> consider BC break implications as serious.
> I already migrated some quite big legacy apps from ` existing tools for this, and I can't even image simpler BC break to deal
> with.


So for me "it will be so hard to upgrade" arguments are also exaggerated,
> and that's why I'm concerned about future BC breaks - if such simple
> change encounters such fierce resistance, then what kind of BC break can
> be accepted?
>
This was exactly my reason for participating in this discussion, if such
simple BC break encounters fierce and lengthy-weighted resistance, I'm not
sure there will ever be a BC break, only additions without a necessary
cleanup.

That's just like, there's a precedent to resist all kinds of BC break
simply because there's no positive impact on the change.

Millions of code can be migrated through many existing libraries in short
time frame to comply with the short tag depreciation.

I think the resistance is actually the reason this discussion(thread) gets
this lengthy.

At the end of all, we either have it or leave it.
Happy coding.

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

Re: [PHP-DEV] Deprecate PHP's short open tags, again

[Chase Peeler]

On Wed, Aug 14, 2019 at 12:22 PM Robert Korulczyk 
wrote:

> > While possibly a bit hyperbolic, most of the arguments basically come
> off that way to me as well. I've definitely viewed most of what you've said
> in
> > that manner.
>
> I guess we're in some kind of limbo where half of the people do not
> consider problems which short open tags create as serious, and other half
> does not
> consider BC break implications as serious.
>
No, we're not. Only people that are in favor of removing short tags seem to
be making this RFC a referendum on BC breaks in general. We understand
there is a security risk. As others have pointed out, it's a rather minor
one. Code gets deployed with short tags onto a server that has short tag
support turned off. The solution is to turn short tags back on. It's a
setting that can be turned on/off at any level, so, just throw it in your
.htaccess file. If you use windows and IIS like me, you can set it in your
registry. Not ideal, but, it works. If there was no way to quickly enable
short tag support, the discussion might be different. Since there is, the
security implications, while they exist, are mitigated.

It's further mitigated by the fact that almost everyone writing portable
code is not using short tags to begin with. This means the odds of me
downloading a 3rd party library that uses short tags is pretty slim. If I
actually do some due diligence (look at the source code, stick to something
actively maintained, something with good reviews, etc) it's even slimmer.
If it's code I'm writing myself, then, I should no better than to write
code with short tags if I'm going to deploy it to a server that doesn't
support them (or that I don't have control over).

As Zeev has mentioned many times, in retrospect, short tags probably should
have never been supported. If they never had been supported, then there
wouldn't be any case for adding support for them now. That doesn't change
the fact that they have been support for 20 years, and removing support for
them now has huge implications for a lot of non-portable legacy code.That
is compared with a security issue, that while it does exist, is very
unlikely to occur for anyone using a modicum of common sense, and can
easily be resolved if it does.


> I already migrated some quite big legacy apps from ` existing tools for this, and I can't even image simpler BC break to deal
> with. So for me "it will be so hard to upgrade" arguments are also
> exaggerated, and that's why I'm concerned about future BC breaks - if such
> simple
> change encounters such fierce resistance, then what kind of BC break can
> be accepted?
>
> Good for you! Come take a stab at my legacy project. It's horrendous. We
have some files where using PhpStorm's automatic formatting actually caused
stuff to break. So, you can see why I might be a little reticent to depend
on an automated tool to change my php tags. I'll let you start with a 12k+
line file of spaghetti code. This file contains a lot of functions (not OO)
used across the legacy parts of the application. As such, it's included at
the top of pretty much every PHP page. So, make sure you don't leave a
typo, because it'll break the entire application!

While you are at it, you can explain to my executive team (I don't work for
a software company) why it's worth putting in the time to modify all these
"don't touch unless it's an emergency" legacy files to upgrade PHP when the
current version seems to be working fine from their perspective.

That's another difference I've seen from the two sides of the argument.
Those in favor of removing them usually say things like "It doesn't seem
like a big deal to me" or "I converted a project and it was really easy" or
"People shouldn't be using short tags anyway, so who cares." While those
against removing them usually say things like "I can see how this could be
a huge problem for a large number of users" or "This could definitely block
a lot of people from upgrading in a timely manner." I'm one of the few
people I've seen that is against removing short tags AND has provided
examples in their own code bases of how it will impact them in a negative
way. Most of those against it have based their opinion on knowing that
others will be negatively impacted by this, even if they personally won't.
Honestly, if it was just my code that was the concern, I wouldn't be as
vocal. I can suck it up and fix things. I can cut through the red tape and
get it done at some point so we can upgrade. I'm vocal on this because I
know there are other developers out there dealing with a legacy code base
like mine, if not worse, that might not be able to just bite the bullet and
get it done.


> Regards,
> Robert Korulczyk
>


-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] Deprecate PHP's short open tags, again

[Robert Korulczyk]

> While possibly a bit hyperbolic, most of the arguments basically come off 
> that way to me as well. I've definitely viewed most of what you've said in
> that manner.

I guess we're in some kind of limbo where half of the people do not consider 
problems which short open tags create as serious, and other half does not
consider BC break implications as serious.
I already migrated some quite big legacy apps from `http://www.php.net/unsub.php

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Ben Ramsey]

> On Aug 14, 2019, at 11:14, Derick Rethans  wrote:
> 
> Hi,
> 
> In the last week(s) there has been a lot of chat about Zeev's P++ idea.
> Before we end up spending this project's time and energy to explore this
> idea further, I thought it'd be wise to see if there is enough animo for
> this. Hence, I've created a document in the wiki as a poll:
> 
> https://wiki.php.net/rfc/p-plus-plus


I voted "no." While I've not contributed to the discussions here, I've
been following them and also reading what many on Twitter have been
saying.

I'll admit, I liked the idea of P++ for the novelty of it, but as the
past has proven, we can continue to provide greater type safety in PHP,
while retaining the dynamic character and flexibility that many enjoy.
In short, the internals team has done a great job of allowing us to
have our cake and eat it, too.

Sara shared this a few days ago, and I’d like to reiterate it:

> Strict(er) typing - I'm not sure, on the surface, what future expansions
> we'd plan for in this area which couldn't fit into standard PHP in a non
> BC-breaking way.

There have been a few people on Twitter floating up the idea of
something like TypeScript for PHP. This might be a better approach for
those who want to significantly diverge from PHP proper. Already, it is
possible to build something like this and have it transpile to PHP. In
the future, perhaps it could even compile down into Zend opcodes that
could be loaded directly into the PHP interpreter. Either way, it
wouldn't change PHP itself, but it could provide the syntactic sugar
and improved type-safety that folks are looking for. More importantly,
it wouldn't split the community or internals.

Cheers,
Ben


signature.asc
Description: Message signed with OpenPGP

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Chase Peeler]

On Wed, Aug 14, 2019 at 11:27 AM Sara Golemon  wrote:

> On Wed, Aug 14, 2019 at 10:14 AM Derick Rethans  wrote:
>
> > https://wiki.php.net/rfc/p-plus-plus
> >
> > To follow up my no vote; What I'm against is splitting the language on
> hard boundaries that never disappear, only widen. I'm also a 'No' on
> Editions, but slightly less of a 'No', and possibly a 'Yes', if those
> editions are clearly intended to fade over time.
>
> -Sara
>
I'd vote "No" if I had a vote. I appreciate Zeev proposing the idea. I've
been as vocal as he has on the short tag issue, and generally fall into the
"avoid BC unless there are overwhelming positives" camp. Maybe I don't have
the complete picture since I don't actually do core development, but I have
been a professional PHP developer for 14 years (Thursday is my 14th
anniversary) and I've been using it for fun/school work for 20 years. From
what I've seen, there isn't near as much contention on BC breaks in general
as a solution like this would require in order to be justified. As someone
mentioned in another thread, the majority of the features discussed (union
types, annotations, enums, etc.) don't require BC breaks at all. Among
things that do require them (both new features and clean up of older
features), I see that most people, myself included, willing to accept them
once they have passed.

I definitely think it's possible to more PHP forward with lots of new
features, and even cleaning up some old and obsolete parts, without moving
too far in either extreme in terms of BC breaks. I also think that
internals has done a pretty good job of that up to this point, and have no
doubt they will continue to do so.

I don't know if it was just a coincidence in timing, but it feels to me
like this proposal was spurred, at least in part, by the discussions over
short tags. If so, I definitely think that it is an overreaction. I also
think the discussions on short tags show why even taking this proposed path
wouldn't solve anything in the long run. The discussion over short tags
have got pretty heated at times, but it seems to me that it is mainly
because both sides are just repeating their talking points without
discussing or answering the points made by the other side. I think that is
partly due to the discussion medium, and partly due to the diversity of the
participants. Without immediate feedback in a manner you expect, it's hard
to tell if the point you just typed out over 5 paragraphs actually made
sense to others that will read it. Bottom line, though, is that there will
be contentious debates about topics no matter what. You might be able to
avoid the debate on whether or not to require strict typing in P++, but
you've still got to decide on which types you're going to support. Strict
typing might never again need to be discussed in legacy PHP, but, there
will always be discussions about some of the more controversial ways that
types are juggled.

There might be a time in the future where I do feel like a proposal like
this is justified or even needed. I just don't feel we are at that point
right now, nor do I think we are headed towards it.

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[sergey]

Hi!

my 2c:

As I understood, Zeev said about two camps: ones want to make PHP more strict, 
others – not.

Maybe, is more productive to discuss the general direction of PHP (it will be a 
strict road or not) instead of 4 months disputes about short open tags, or 
sisters language or other derivative things?

IMHO, if there is a single direction, many disputes will disappear by themselves

—
Sincerely,
Sergey Panteleev
Telegram: @saundefined
E-mail: ser...@s-panteleev.ru
On 14 Aug 2019, 18:27 +0300, Sara Golemon , wrote:
> On Wed, Aug 14, 2019 at 10:14 AM Derick Rethans  wrote:
>
> > https://wiki.php.net/rfc/p-plus-plus
> >
> > To follow up my no vote; What I'm against is splitting the language on
> hard boundaries that never disappear, only widen. I'm also a 'No' on
> Editions, but slightly less of a 'No', and possibly a 'Yes', if those
> editions are clearly intended to fade over time.
>
> -Sara

Re: [PHP-DEV] Deprecate PHP's short open tags, again

[Chase Peeler]

On Wed, Aug 14, 2019 at 10:49 AM Robert Korulczyk 
wrote:

> > This discussion has gone out of sanity levels the moment people started
> to state that short tags is one (of the many)
> > things PHP has why new programmers and companies don't pick the language
> or why colleagues laugh at you and is a
> > blocker of new bright future etc. and now in this moment this is a do or
> die situation otherways next year everyone
> > will be writing in javascript.
>
> No one said that (except you).
>
> While possibly a bit hyperbolic, most of the arguments basically come off
that way to me as well. I've definitely viewed most of what you've said in
that manner.


> But current reaction for this RFC could be depressing. I'm using PHP for
> quite a long time and I really hoped that someday we'll be able to get rid
> of
> all (or at least the most of them) the traps and annoying little things
> from the old days. That doesn't sound realistic anymore...
>
> This is exactly what we're talking about. You act as if leaving short tags
in PHP means nothing will ever get cleaned up. That there is absolutely no
reason at all we might want to consider leaving them, so, the fact that we
are is just a signal that no one is willing to entertain the idea of BC
breaks for anything ever.

>
> > Except there are 4-5 functions which do the same not to mention ``
> backtick syntax (can't there be an accident mixing those with single
> quotes?).
>
> I was talking about all these functions that allows to execute shell
> commands. What is the point of disabling only one of them? I thought that
> the
> problem is in functionality, not in the name :P
>
> Or, maybe, it's just that the negative consequences of removing those
functions doesn't justify the positives that would be gained? That's the
whole argument with short tags. It's not "Short tags are wonderful!" or
"There is absolutely NOTHING bad about short tags and how they are
currently handled." We've just been saying that while there are negatives,
they are negatives that have existed for 20 years without causing large
scale issues. The issues they cause do not justify removing them and the
impact it will have on existing developers and code bases. It causes a
large amount of difficulty for many people to upgrade while only solving a
possible security issue that is actually pretty easy to avoid.

Honestly, while I didn't have a vote, if the RFC didn't include language
about actually removing short tag support in PHP 9, I would have encouraged
people to support it. I have no issues with helping push people towards not
using short tags, and then at some point in the future discussing whether
to remove support or not.

In the end, what I see is one side (those for keeping short tag support)
readily admitting that there are issues with short tags, but they aren't
outweighed by the negatives. I see the other side (those for removing short
tag support) acting as if there were absolutely no negatives at all to
removing them. You even said exactly that: "Since we don't have any good
cause to leave it be, let it go." They also inflate the issues with short
tags to hyperbolic levels, making them into a huge security implication,
the driving force behind anti-PHP sentiment, and the barrier to new
developers picking up the language. That makes it impossible to have a
reasoned discussion on the argument. It's like one side is saying "I know
fire is dangerous, but I think it's a good idea to have some matches handy
just in case." And the other side saying "No, if we have matches no one
will ever come to our house and all of our neighbors will laugh at us and
we'll almost definitely burn the house down." Even though you've had
matches in the house for the last 20 years without any issues.


> >> `` is intended usage of short open tags.
> >
> > On this I could also say that recommendations are to store all
> credentials outside webroot,
>
>
> I'm afraid you don't understand the problem. Having such code outside of
> webroot does not help you much if this file will be included from another
> file (which uses ` password is just the simplest example - single non-working `if` can lead to
> a
> wide range of bugs with serious consequences, far beyond code leak.
>
> What about the display_errors ini directive? That seems like a security
risk as well, since error messages can contain sensitive information. I
know keeping/removing it isn't mutually exclusive with keeping/removing
short tags. I'm just curious why it's never mentioned by anyone that
suddenly is so concerned about the security implications of short tags.

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

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Sara Golemon]

On Wed, Aug 14, 2019 at 10:14 AM Derick Rethans  wrote:

> https://wiki.php.net/rfc/p-plus-plus
>
> To follow up my no vote; What I'm against is splitting the language on
hard boundaries that never disappear, only widen. I'm also a 'No' on
Editions, but slightly less of a 'No', and possibly a 'Yes', if those
editions are clearly intended to fade over time.

-Sara

[PHP-DEV] Vote: Straw poll for P++ feasibility

[Derick Rethans]

Hi,

In the last week(s) there has been a lot of chat about Zeev's P++ idea. 
Before we end up spending this project's time and energy to explore this 
idea further, I thought it'd be wise to see if there is enough animo for 
this. Hence, I've created a document in the wiki as a poll:

https://wiki.php.net/rfc/p-plus-plus

cheers,
Derick

-- 
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Become my Patron: https://www.patreon.com/derickr
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] Deprecate PHP's short open tags, again

[Robert Korulczyk]

> This discussion has gone out of sanity levels the moment people started to 
> state that short tags is one (of the many) 
> things PHP has why new programmers and companies don't pick the language or 
> why colleagues laugh at you and is a 
> blocker of new bright future etc. and now in this moment this is a do or die 
> situation otherways next year everyone 
> will be writing in javascript.

No one said that (except you).

But current reaction for this RFC could be depressing. I'm using PHP for quite 
a long time and I really hoped that someday we'll be able to get rid of
all (or at least the most of them) the traps and annoying little things from 
the old days. That doesn't sound realistic anymore...


> Except there are 4-5 functions which do the same not to mention `` backtick 
> syntax (can't there be an accident mixing those with single quotes?).

I was talking about all these functions that allows to execute shell commands. 
What is the point of disabling only one of them? I thought that the
problem is in functionality, not in the name :P


>> `` is intended usage of short open tags.
> 
> On this I could also say that recommendations are to store all credentials 
> outside webroot, 


I'm afraid you don't understand the problem. Having such code outside of 
webroot does not help you much if this file will be included from another
file (which uses `http://www.php.net/unsub.php

RE: [PHP-DEV] Deprecate PHP's short open tags, again

[Reinis Rozitis]

> Please, let's keep this discussion at some level of sanity... You basically 
> need
> stick to static HTML if you're considering possibility of such exec() usage 
> as a
> security issue.

This discussion has gone out of sanity levels the moment people started to 
state that short tags is one (of the many) things PHP has why new programmers 
and companies don't pick the language or why colleagues laugh at you and is a 
blocker of new bright future etc. and now in this moment this is a do or die 
situation otherways next year everyone will be writing in javascript.


> 1. exec-like functions have their purpose without any straight-forward 
> alternative, while ` `` is intended usage of short open tags.

On this I could also say that recommendations are to store all credentials 
outside webroot, but again it also qualify as something different than by 
accident generated code in IDE, just to show that the "security issue" can be 
stretched however you like.


> You basically need stick to static HTML

Maybe. 
But let's end at this ..

rr




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

Re: [PHP-DEV] Deprecate PHP's short open tags, again

[Chase Peeler]

On Wed, Aug 14, 2019 at 7:03 AM Olumide Samson 
wrote:

> On Wed, Aug 14, 2019, 11:24 AM Peter Kokot  wrote:
>
> > On Wed, 14 Aug 2019, 12:09 Reinis Rozitis,  wrote:
> >
> > > > It is surprising how thing that is considered by one to be a security
> > > risk, is treated
> > > > as nothing relevant by others. This dichotomy is quite disturbing -
> in
> > > what case
> > > > removing security risk is "no real gain"?
> > >
> > > It's questionable that a misconfigured environment is a "security" risk
> > > caused by language rather than ignorance of the administrator.
> > >
> > > On that matter you could ask why are all the exec/passthru/proc_open
> etc
> > > functions/features are allowed by default while every other guide on
> > > hardening web suggests those to be disabled (added to
> disable_functions)?
> > > I would bet there have been a lot more (actual) security breaches
> because
> > > of unsanitized/unescaped parameters to those.
> > >
> > > Just to repeat some other people - there are a lot other things to work
> > on
> > > than this.
> > >
> > > rr
> > >
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> > Appologies if these short tags are bumped so many times and cause so much
> > issues but we are at the very starting discussions of PHP 8 also. Major
> > version, where breaking thing was supposed to be possible. So that is one
> > of the reasons why this and similar cleanups are mentioned in the first
> > place. With closing the door to even talk and work on cleanups, or being
> > ashamed of it, or bully others because they want to have a better
> structure
> > with using PHP 8+, nothing good can come out of it.
> >
> > >
> > >
> > >
> >
> I'm with you on this PHP 8 argument.
> I think many of this popular languages that's making my PHP professional
> coding look like kids play make sure their major version shake up many old
> things, to cleanup old things that's either better not released or would
> cause some developers to write environment-tied programs.
> Since we don't have any good cause to leave it be, let it go.
>
> Let the user land developers see PHP as a major language they are hoping
> for.
>
> Currently, it's easy to learn, use, break or make.
> Let them see the intern devs are strict and mature enough to break things
> when needed and when possible.
>
> Break it off if it's not useful or would allow the possibility to write
> environment tied code(where short tag is not a general idea) and what are
> we saying? PHP 8 needs major shake up, let's start it from PHP 7 and let
> the world wow at the internals courage, focus and super ability to
> implement what's needed. Why wait for a time, when we have little time?
> Should we wait for cleanups until PHP 9 or PHP 10?
> Im sure javascript would have moved on around that time as the same
> language for web, mobile and desktop application, while PHP a major
> language still keep in doing its stuff at the server side(and the user land
> get booed as boring programmer who would have to learn multiple languages
> to get a desktop, mobile and web application designed).
>
> Please,clean up.
>
> >
>

The "shake-ups" that will draw people to PHP are the new features, the
majority of which don't require BC breaks and were listed earlier in this
thread. Go find a group of anti-PHP developers. Tell them how wonderful PHP
9 is going to be. When they ask why, tell them "We've got rid of short
tags!" and see how they react. Now, find another group of anti-PHP
developers. Tell them how wonderful PHP 9 is going to be. Tell them it will
have generics, enums, union types, and JIT. Also mention that short tags
will still be allowed. See how they react. They might not really care, and
still not like PHP, but I can guarantee you it won't be because short tags
still exist.


-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] Deprecate PHP's short open tags, again

[Robert Korulczyk]

W dniu 14.08.2019 o 14:14, Reinis Rozitis pisze:
> Depends on how you look at if exec($_GET['param']) is a language 
> responsibility or programmers?

Please, let's keep this discussion at some level of sanity... You basically 
need stick to static HTML if you're considering possibility of such exec()
usage as a security issue.

They're at least 3 main deferences between short open tags and exec-like 
functions:

1. exec-like functions have their purpose without any straight-forward 
alternative, while `` is intended usage of short open tags.
3. Because of point 2, there is no IDE or editor which will generate code like 
`exec($_GET['param'])`, while there is at least one popular IDE which
will generate code with short open tags.


Regards,
Robert Korulczyk

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

RE: [PHP-DEV] Deprecate PHP's short open tags, again

[Reinis Rozitis]

> Honestly, I don't see how allowing exec/passthru/proc_open is a security risk.
> These are just tools. We're talking about programming language - if you're
> running PHP script as user X you should expect that it could do anything that 
> user
> X can do. If you don't trust this script, just don't run it

Depends on how you look at if exec($_GET['param']) is a language responsibility 
or programmers?

On the same level you can then expect that programmer X always uses ' https://www.php.net/manual/en/language.basic-syntax.phptags.php
> 
> "PHP also allows for short open tag  available if enabled using the short_open_tag php.ini configuration file 
> directive,
> or if PHP was configured with the --enable-short-tags option)."

Which is actually the other way around - enabled by default / disabled if 
configured via ini.

It feels most people who argue about the feature (are not in the burn it with 
fire and everyone who uses them should just go away) would be fine (enough) if 
it aligned to what's written in the documentation and then make deliberate 
decision to enable those.

rr 


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

Re: [PHP-DEV] Deprecate PHP's short open tags, again

[Robert Korulczyk]

> Sure those are important - I was just pointing out that the "security card" 
> is questionable since the language has more dangerous features
> which ask for the user to be careful and responsible about them rather than 
> making everything foolproof and accident-free.

Honestly, I don't see how allowing exec/passthru/proc_open is a security risk. 
These are just tools. We're talking about programming language - if
you're running PHP script as user X you should expect that it could do anything 
that user X can do. If you don't trust this script, just don't run it
- disabling exec/passthru/proc_open does not change much since PHP is powerful 
enough to hurt you badly without executing any shell commands.

If you think that disabling exec function will protect you from malicious 
scripts, then you have real security problem related directly to your
environment and completely unrelated to PHP (it is OS responsibility to 
disallow access to part of the system, which should not be accessed by a
particular program).

> Considering the current RFCs has it really been decided as "don't use it" 
> (when/where?)? 

https://www.php.net/manual/en/language.basic-syntax.phptags.php

"PHP also allows for short open tag http://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate PHP's short open tags, again

[Olumide Samson]

On Wed, Aug 14, 2019, 11:24 AM Peter Kokot  wrote:

> On Wed, 14 Aug 2019, 12:09 Reinis Rozitis,  wrote:
>
> > > It is surprising how thing that is considered by one to be a security
> > risk, is treated
> > > as nothing relevant by others. This dichotomy is quite disturbing - in
> > what case
> > > removing security risk is "no real gain"?
> >
> > It's questionable that a misconfigured environment is a "security" risk
> > caused by language rather than ignorance of the administrator.
> >
> > On that matter you could ask why are all the exec/passthru/proc_open etc
> > functions/features are allowed by default while every other guide on
> > hardening web suggests those to be disabled (added to disable_functions)?
> > I would bet there have been a lot more (actual) security breaches because
> > of unsanitized/unescaped parameters to those.
> >
> > Just to repeat some other people - there are a lot other things to work
> on
> > than this.
> >
> > rr
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
>
> Appologies if these short tags are bumped so many times and cause so much
> issues but we are at the very starting discussions of PHP 8 also. Major
> version, where breaking thing was supposed to be possible. So that is one
> of the reasons why this and similar cleanups are mentioned in the first
> place. With closing the door to even talk and work on cleanups, or being
> ashamed of it, or bully others because they want to have a better structure
> with using PHP 8+, nothing good can come out of it.
>
> >
> >
> >
>
I'm with you on this PHP 8 argument.
I think many of this popular languages that's making my PHP professional
coding look like kids play make sure their major version shake up many old
things, to cleanup old things that's either better not released or would
cause some developers to write environment-tied programs.
Since we don't have any good cause to leave it be, let it go.

Let the user land developers see PHP as a major language they are hoping
for.

Currently, it's easy to learn, use, break or make.
Let them see the intern devs are strict and mature enough to break things
when needed and when possible.

Break it off if it's not useful or would allow the possibility to write
environment tied code(where short tag is not a general idea) and what are
we saying? PHP 8 needs major shake up, let's start it from PHP 7 and let
the world wow at the internals courage, focus and super ability to
implement what's needed. Why wait for a time, when we have little time?
Should we wait for cleanups until PHP 9 or PHP 10?
Im sure javascript would have moved on around that time as the same
language for web, mobile and desktop application, while PHP a major
language still keep in doing its stuff at the server side(and the user land
get booed as boring programmer who would have to learn multiple languages
to get a desktop, mobile and web application designed).

Please,clean up.

>

RE: [PHP-DEV] Deprecate PHP's short open tags, again

[Reinis Rozitis]

> This is about accidental usage of *language* feature, which *by design* can 
> lead to code leaks (so application bug, not misconfigured environment). 
> Clearly not a language problem that it has dedicated feature to shoot 
> yourself in the foot...
> 
> These methods have their purpose (pretty important BTW), short open tags is
> just "don't use it!!!" feature.

Sure those are important - I was just pointing out that the "security card" is 
questionable since the language has more dangerous features which ask for the 
user to be careful and responsible about them rather than making everything 
foolproof and accident-free.


Also it's not by design - the only way code can leak is when it has been using 
'http://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate PHP's short open tags, again

[Robert Korulczyk]

W dniu 14.08.2019 o 12:09, Reinis Rozitis pisze:
> It's questionable that a misconfigured environment is a "security" risk 
> caused by language rather than ignorance of the administrator. 

This is not about misconfigured environment. This is about accidental usage of 
*language* feature, which *by design* can lead to code leaks (so
application bug, not misconfigured environment). Clearly not a language problem 
that it has dedicated feature to shoot yourself in the foot...

> On that matter you could ask why are all the exec/passthru/proc_open etc 
> functions/features are allowed by default while every other guide on
hardening web suggests those to be disabled (added to disable_functions)?

These methods have their purpose (pretty important BTW), short open tags is 
just "don't use it!!!" feature.


Regards,
Robert Korulczyk

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

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[Michał Brzuchalski]

śr., 14 sie 2019 o 12:17 Michał Brzuchalski 
napisał(a):

>
>
> śr., 14 sie 2019 o 12:11 Rowan Collins 
> napisał(a):
>
>> On 14/08/2019 11:07, Michał Brzuchalski wrote:
>> > Exactly so how would it know from string name either it should load
>> class
>> > from src/Foo.php or src/__nsmeta.php if there is no information?
>>
>>
>> It wouldn't. It would include src/Foo.php, and that would have the
>> definition of something with the name "Foo" - either a class, an
>> interface, a trait, or a package. If it wasn't what the engine was
>> expecting, it would be an error, just as it is right now if you write
>> "implements ClassName", or "new TraitName();"
>>
>
> Following that would introduce unneeded additional directory hierarchy
> level in a usual library
> which uses PSR-4 which is the most used one, right?
>
> /composer.json
> /src/Foo.php
> /src/Foo/ <- all package classes should go here?
>

Going even further by the example of Doctrine libraries:
# doctrine/collections - Composer Package [1]
uses PSR-4 autoload with "Doctrine\\Common\\Collections\\" prefix
to adopt package concept it would have to change the prefix to
"Doctrine\\Common\\"
to find Collections.php and all the rest of source code in Collections
directory

# doctrine/common - Composer Package [2]
uses "Doctrine\\Common\\" prefix should change into "Doctrine\\" to be able
to load
Common.php and the rest of source code in Common directory

# ocramius/package-versions - Composer Package [3]
uses "PackageVersions\\" prefix and then what?

[1] https://github.com/doctrine/collections/blob/master/composer.json
[2] https://github.com/doctrine/common/blob/master/composer.json
[3] https://github.com/Ocramius/PackageVersions/blob/master/composer.json
-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[Rowan Collins]

On 14/08/2019 11:17, Michał Brzuchalski wrote:

Following that would introduce unneeded additional directory hierarchy
level in a usual library
which uses PSR-4 which is the most used one, right?

/composer.json
/src/Foo.php
/src/Foo/  <- all package classes should go here?



That would be one place to put it, yes. But it would be entirely up to 
how people wanted to define their autoloader, that's the beauty of it.


There's no reason something couldn't generate an autoloader that 
essentially said this:


function autoload($name) {
   if ( $name == self::PACKAGE_NAME ) {
  require self::SRC_DIR . '/__packagedef.php';
   } elseif ( str_begins_with($name, self::BASE_NAMESPACE) ) {
  require self::SRC_DIR . str_replace('\\', '/', $name) . '.php';
   }
}

Please don't pick holes in that implementation; my point is, if this was 
how packages were implemented, people would decide how they wanted to 
use it, and PSR-4 would probably be superseded by something which 
accounted for packages existing.


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] Deprecate PHP's short open tags, again

[Peter Kokot]

On Wed, 14 Aug 2019, 12:09 Reinis Rozitis,  wrote:

> > It is surprising how thing that is considered by one to be a security
> risk, is treated
> > as nothing relevant by others. This dichotomy is quite disturbing - in
> what case
> > removing security risk is "no real gain"?
>
> It's questionable that a misconfigured environment is a "security" risk
> caused by language rather than ignorance of the administrator.
>
> On that matter you could ask why are all the exec/passthru/proc_open etc
> functions/features are allowed by default while every other guide on
> hardening web suggests those to be disabled (added to disable_functions)?
> I would bet there have been a lot more (actual) security breaches because
> of unsanitized/unescaped parameters to those.
>
> Just to repeat some other people - there are a lot other things to work on
> than this.
>
> rr
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php


Appologies if these short tags are bumped so many times and cause so much
issues but we are at the very starting discussions of PHP 8 also. Major
version, where breaking thing was supposed to be possible. So that is one
of the reasons why this and similar cleanups are mentioned in the first
place. With closing the door to even talk and work on cleanups, or being
ashamed of it, or bully others because they want to have a better structure
with using PHP 8+, nothing good can come out of it.

>
>
>

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[Michał Brzuchalski]

śr., 14 sie 2019 o 12:11 Rowan Collins  napisał(a):

> On 14/08/2019 11:07, Michał Brzuchalski wrote:
> > Exactly so how would it know from string name either it should load class
> > from src/Foo.php or src/__nsmeta.php if there is no information?
>
>
> It wouldn't. It would include src/Foo.php, and that would have the
> definition of something with the name "Foo" - either a class, an
> interface, a trait, or a package. If it wasn't what the engine was
> expecting, it would be an error, just as it is right now if you write
> "implements ClassName", or "new TraitName();"
>

Following that would introduce unneeded additional directory hierarchy
level in a usual library
which uses PSR-4 which is the most used one, right?

/composer.json
/src/Foo.php
/src/Foo/ <- all package classes should go here?

-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[Rowan Collins]

On 14/08/2019 11:07, Michał Brzuchalski wrote:

Exactly so how would it know from string name either it should load class
from src/Foo.php or src/__nsmeta.php if there is no information?



It wouldn't. It would include src/Foo.php, and that would have the 
definition of something with the name "Foo" - either a class, an 
interface, a trait, or a package. If it wasn't what the engine was 
expecting, it would be an error, just as it is right now if you write 
"implements ClassName", or "new TraitName();"


Regards,

--
Rowan Collins
[IMSoP]


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

RE: [PHP-DEV] Deprecate PHP's short open tags, again

[Reinis Rozitis]

> It is surprising how thing that is considered by one to be a security risk, 
> is treated
> as nothing relevant by others. This dichotomy is quite disturbing - in what 
> case
> removing security risk is "no real gain"?

It's questionable that a misconfigured environment is a "security" risk caused 
by language rather than ignorance of the administrator. 

On that matter you could ask why are all the exec/passthru/proc_open etc 
functions/features are allowed by default while every other guide on hardening 
web suggests those to be disabled (added to disable_functions)?
I would bet there have been a lot more (actual) security breaches because of 
unsanitized/unescaped parameters to those.

Just to repeat some other people - there are a lot other things to work on than 
this.

rr


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

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[Michał Brzuchalski]

śr., 14 sie 2019 o 11:49 Rowan Collins  napisał(a):

> > You suggest that it would trigger autoload to load "MyVendor\MyPackage"
> > but current autoload machinery is able to load only classes,
> > not even functions or consts! cause it gets the only class name now.
> > It would need to be changed anyway.
>
>
> As I said in another reply, this is only the same change that needed to
> be made to support "trait" alongside "class" and "interface", or would
> be needed to support "enum" or "struct". The userland part of the
> autoloader already doesn't know which of those it's looking for, so the
> only constraint is that the names can't collide, so you couldn't name a
> package the same thing as a class.
>
>
Exactly so how would it know from string name either it should load class
from src/Foo.php or src/__nsmeta.php if there is no information?

-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] Deprecate PHP's short open tags, again

[Robert Korulczyk]

W dniu 14.08.2019 o 11:09, Christian Schneider pisze:
> Am 14.08.2019 um 10:39 schrieb Peter Kokot :
>>> The best counterargument I can give against "cleaning up" is that it takes 
>>> energy away from actual new features, even if it's just the mental energy 
>>> of monitoring and responding to long threads like this one.
>>
>> Code is like a garden. If there are unwanted weeds and nobody cleans
>> them up, the flowers don't shine and grow as they should.  Cleaning of
>> the weeds is just as important as new features. A bit less but
>> important.
> 
> Going with your analogy: Some things (like short open tags) are that 
> individual small flower in the corner of the garden which does not multiply. 
> We already spent way too much time discussing it, the rest of the garden 
> needs water and the gardeners are fighting over a dandelion. A bike-shed 
> discussion at its worst: No real gain but everybody has an opinion.
> Real cleaning up, now that's where it gets interesting. And those discussions 
> tend to be more productive even recently.
> 
> Oh and: I'm very much afraid the OP was trolling and succeeded in getting 
> people to react, so please, please let this particular thread die :-(
> 
> - Chris
> 
> 

It is surprising how thing that is considered by one to be a security risk, is 
treated as nothing relevant by others. This dichotomy is quite
disturbing - in what case removing security risk is "no real gain"?

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

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[Rowan Collins]

On 14/08/2019 10:27, Michał Brzuchalski wrote:
But that's conflicting with you above idea for package definition like 
that:




That's not what I'm suggesting; perhaps my example could have been 
clearer. I envisage two new keywords:


- To put some code in a package, you would write "package Foo;" at the 
top of a file, or "package Foo { }" around a block, in the same way you 
can do now for namespaces and declare() statements.
- To define a package before it is used, you would write "packagedef Foo 
{ }" around some block of pseudo-PHP that defined the options for that 
package. That might involve using declare() directly, or might just be 
an array that defines the options.




You suggest that it would trigger autoload to load "MyVendor\MyPackage"
but current autoload machinery is able to load only classes,
not even functions or consts! cause it gets the only class name now.
It would need to be changed anyway.



As I said in another reply, this is only the same change that needed to 
be made to support "trait" alongside "class" and "interface", or would 
be needed to support "enum" or "struct". The userland part of the 
autoloader already doesn't know which of those it's looking for, so the 
only constraint is that the names can't collide, so you couldn't name a 
package the same thing as a class.


There are other problems with autoloading functions and constants, but 
the relevant point is that you can define function foo() {} and class 
foo {} in the same namespace; as long as you couldn't also have a 
separate package foo{}, it could share the same autoloader as classes, 
interfaces, and traits.


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[Michał Brzuchalski]

śr., 14 sie 2019 o 11:01 Rowan Collins  napisał(a):

> I don't see this as a problem. Right now, PHP doesn't care how many
> files you put your code in. As far as I know, you could concatenate the
> entirety of Laravel into one PHP file, and applications would not be
> able to tell the difference. Similarly, you could put the whole thing in
> a database and use eval() to execute it without touching any files.
>
>
That is true but not if there are any declare statements. If so it could
IMO work only like that:
 I think what attracts me to this idea is precisely that it doesn't
> require much extra machinery. We could even use the trick that PHPStorm
> uses for metadata stubs [1], and make the package definition look like
> valid executable PHP, but never actually execute it:
>
> package Foo {
>  const declare = [
> 'strict_types' => 1,
> 'strict_operators' => 1
>  ];
> }
>

How could that know when need look for package definition?
Example:

# src/Foo.php

Re: [PHP-DEV] Deprecate PHP's short open tags, again

[Peter Kokot]

On Wed, 14 Aug 2019 at 11:09, Christian Schneider  wrote:
>
> Am 14.08.2019 um 10:39 schrieb Peter Kokot :
> >> The best counterargument I can give against "cleaning up" is that it takes 
> >> energy away from actual new features, even if it's just the mental energy 
> >> of monitoring and responding to long threads like this one.
> >
> > Code is like a garden. If there are unwanted weeds and nobody cleans
> > them up, the flowers don't shine and grow as they should.  Cleaning of
> > the weeds is just as important as new features. A bit less but
> > important.
>
> Going with your analogy: Some things (like short open tags) are that 
> individual small flower in the corner of the garden which does not multiply. 
> We already spent way too much time discussing it, the rest of the garden 
> needs water and the gardeners are fighting over a dandelion. A bike-shed 
> discussion at its worst: No real gain but everybody has an opinion.
> Real cleaning up, now that's where it gets interesting. And those discussions 
> tend to be more productive even recently.
>
> Oh and: I'm very much afraid the OP was trolling and succeeded in getting 
> people to react, so please, please let this particular thread die :-(
>
> - Chris

I'm sorry but until the RFC is still in voting phase, participants
should be welcome to express opinions. And the message by OP was
correct. PHP is having a lot of these old sins and they are standing
out, yes.


-- 
Peter Kokot

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

Re: [PHP-DEV] Deprecate PHP's short open tags, again

[Christian Schneider]

Am 14.08.2019 um 10:39 schrieb Peter Kokot :
>> The best counterargument I can give against "cleaning up" is that it takes 
>> energy away from actual new features, even if it's just the mental energy of 
>> monitoring and responding to long threads like this one.
> 
> Code is like a garden. If there are unwanted weeds and nobody cleans
> them up, the flowers don't shine and grow as they should.  Cleaning of
> the weeds is just as important as new features. A bit less but
> important.

Going with your analogy: Some things (like short open tags) are that individual 
small flower in the corner of the garden which does not multiply. We already 
spent way too much time discussing it, the rest of the garden needs water and 
the gardeners are fighting over a dandelion. A bike-shed discussion at its 
worst: No real gain but everybody has an opinion.
Real cleaning up, now that's where it gets interesting. And those discussions 
tend to be more productive even recently.

Oh and: I'm very much afraid the OP was trolling and succeeded in getting 
people to react, so please, please let this particular thread die :-(

- Chris


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

Re: [PHP-DEV] Re: Deprecate PHP's short open tags, again

[Rowan Collins]

On 14/08/2019 09:39, Peter Kokot wrote:

Code is like a garden. If there are unwanted weeds and nobody cleans
them up, the flowers don't shine and grow as they should.  Cleaning of
the weeds is just as important as new features. A bit less but
important.



It's a pretty analogy, but I don't think it works. The things that make 
weeds a problem are that they take up space, they take up nutrients, and 
they spread. I don't think short open tags does any of those things.


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[Rowan Collins]

On 14/08/2019 07:45, Michał Brzuchalski wrote:

It doesn't have to be a new syntax if we agree to put package definiction
in sort of separate configuration file.



With the exception of INI files, all your examples are new syntax, as 
far as the internal mechanisms in PHP are concerned. They have the 
advantage of not inventing our own, but the disadvantage of needing our 
parser to handle all the ways people might write them (particularly true 
for YAML).




That way it would prevent to mix normal PHP code with package definition,
cause every possible PHP syntax
we would agree, opens the door to add something more to that file, for eg.:

# package.php



I don't see this as a problem. Right now, PHP doesn't care how many 
files you put your code in. As far as I know, you could concatenate the 
entirety of Laravel into one PHP file, and applications would not be 
able to tell the difference. Similarly, you could put the whole thing in 
a database and use eval() to execute it without touching any files.


In the same way, we can have a package definition not as a configuration 
file, but as a piece of PHP code that needs to have been executed. In 
practice, people wouldn't write what you have there for the same reason 
they don't write this:


# foo.php
I think what attracts me to this idea is precisely that it doesn't 
require much extra machinery. We could even use the trick that PHPStorm 
uses for metadata stubs [1], and make the package definition look like 
valid executable PHP, but never actually execute it:


package Foo {
    const declare = [
   'strict_types' => 1,
   'strict_operators' => 1
    ];
}

That way, we can probably reuse the whole parser infrastructure, and it 
looks entirely natural to a PHP programmer.



[1]: 
https://blog.jetbrains.com/phpstorm/2019/02/new-phpstorm-meta-php-features/


--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] Re: Deprecate PHP's short open tags, again

[Peter Kokot]

On Wed, 14 Aug 2019 at 10:11, Rowan Collins  wrote:
>
> On 13 August 2019 19:19:42 BST, Olumide Samson  wrote:
> >Not sure what the counter argument is really driving at.
> >So, because some people are using a function or an unworthy directive,
> >then
> >there can't be a major change in that aspect?
>
>
> That's not what anyone is saying. What people are saying is that we shouldn't 
> just make changes because we feel like it; there should be a strong reason 
> for the change. Most people probably even agree up to that point, but 
> disagree with whether the reasons given for this particular case are strong 
> enough.
>
>
> >Not sure where this project is headed, some will want a code to stay
> >because they want easy version upgrade(must everyone upgrade? ) and
> >those
> >who want to shake things up won't be allowed to do so.
>
>
> I find it really frustrating that this feature, that most people had probably 
> forgotten even existed, has somehow been taken as an example of the pressing 
> need for change.
>
> If you propose something that will actually take the language forward, but 
> needs to break a few things along the way, then you might have a valid 
> complaint about lack of vision. But there is no feature which will be 
> unlocked by removing short tags; no big selling point we can talk about at 
> conferences; it will either work, or it won't, and most people's code will 
> not be affected one way or the other.
>
> Most people's wishlists for PHP, even some of the posts in this thread, 
> include things like generics, union types, enums, CoW classes/structs, 
> annotations. To my knowledge, none of those is currently being blocked by the 
> need for backwards compatibility; most are being blocked because they're hard 
> to design, and hard to implement.
>
> The best counterargument I can give against "cleaning up" is that it takes 
> energy away from actual new features, even if it's just the mental energy of 
> monitoring and responding to long threads like this one.
>
> Regards,

Code is like a garden. If there are unwanted weeds and nobody cleans
them up, the flowers don't shine and grow as they should.  Cleaning of
the weeds is just as important as new features. A bit less but
important.


-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] Namespace-scoped declares, again

[Rowan Collins]

On 13/08/2019 23:28, Mark Randall wrote:

On 13/08/2019 21:26, Rowan Collins wrote:
Ah, that makes sense. Does that necessarily mean we need a dummy 
class, though? The autoloading logic in the engine knows that it 
called the autoload callback expecting a package definition, so can 
count as success that the package is now defined.


In other words, the file the autoloader included would look like this 
(again, sticking to the notion that "package" is separate from 
"namespace"):


Personally with file-level opt ins I'm not 100% sold on the benefits 
of packages over namespace level information. I guess I'm not certain 
on what problem they're trying to solve that's different from just 
another object at namespace level.



The problem they're trying to solve is that at the moment, there is no 
namespace-level information. Namespaces form an arbitrarily deep 
hierarchy, and don't need to be declared before they're used; it's hard 
to retrofit configuration into that. In my mind a package would be very 
similar to a namespace, but would have a mandatory declaration 
somewhere, giving a place to define its settings and properties; and 
there would be no "sub-packages", so no need to define inheritance and 
over-rides.



As for the dummy class, the only real benefit is that existing 
autoloading procedures can be used to locate it and be included with 
minimal overhead.


PHP can call the autoloader internally but it would require userland 
loaders to be upgraded with it, not exactly a huge stretch, especially 
with most things being composer-based, but a dummy class would make it 
work out the box, including optimization steps like dumping the class 
list.



I see what you mean; but the change needed to autoloaders would be 
pretty minimal: if they just turn the name into a file path and run 
file_exists(), no change at all; if they tokenize files in advance to 
build a class map, they would need to add "packagedef" to the list of 
tokens to search for, alongside "class", "interface", and "trait". The 
same change would be needed if we introduced a "struct" or "enum" 
keyword, and I don't think anyone would expect to write dummy classes 
alongside those.



Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] Re: Deprecate PHP's short open tags, again

[Rowan Collins]

On 13 August 2019 19:19:42 BST, Olumide Samson  wrote:
>Not sure what the counter argument is really driving at.
>So, because some people are using a function or an unworthy directive,
>then
>there can't be a major change in that aspect?


That's not what anyone is saying. What people are saying is that we shouldn't 
just make changes because we feel like it; there should be a strong reason for 
the change. Most people probably even agree up to that point, but disagree with 
whether the reasons given for this particular case are strong enough.


>Not sure where this project is headed, some will want a code to stay
>because they want easy version upgrade(must everyone upgrade? ) and
>those
>who want to shake things up won't be allowed to do so.


I find it really frustrating that this feature, that most people had probably 
forgotten even existed, has somehow been taken as an example of the pressing 
need for change.

If you propose something that will actually take the language forward, but 
needs to break a few things along the way, then you might have a valid 
complaint about lack of vision. But there is no feature which will be unlocked 
by removing short tags; no big selling point we can talk about at conferences; 
it will either work, or it won't, and most people's code will not be affected 
one way or the other.

Most people's wishlists for PHP, even some of the posts in this thread, include 
things like generics, union types, enums, CoW classes/structs, annotations. To 
my knowledge, none of those is currently being blocked by the need for 
backwards compatibility; most are being blocked because they're hard to design, 
and hard to implement.

The best counterargument I can give against "cleaning up" is that it takes 
energy away from actual new features, even if it's just the mental energy of 
monitoring and responding to long threads like this one.

Regards,

-- 
Rowan Collins
[IMSoP]

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