A plea for unity on scalar types

11 years ago by Anthony Ferrara — view source — reply

unread

All,

There's something that I think needs to be said about the now 3 scalar
type proposals. Please bear with me, there's a lot to say here. I'll
try to keep it as brief as I can.

I've been working off-and-on on scalar types for over 3 years. I've
officially proposed 3 proposals and have discussed and played with
many more versions. After I left, Andrea mentioned to me that she
wanted to pick one up. So I helped her. I worked with her for months
on what was ultimately withdrawn
(https://wiki.php.net/rfc/scalar_type_hinting_with_cast). At that
point I resigned to the fact that it wasn't possible to do scalar
types in PHP.

Andrea proved me wrong. When she came up with the dual-mode RFC in
0.3, it was the first proposal that either of us worked on that even
had a shot of passing. She put it up to vote slightly prematurely, but
the votes were pretty clear that it was basically what people wanted,
but with a few minor "issues". When she abandoned it, I picked it up.
Partly because I wanted to see it pass (I think it's the right
proposal), but partly because I didn't want to see her efforts go in
vain by people who didn't even understand the why.

So let me explain what I learned through that experience. Why I chose
to pick the dual mode RFC back up. Why I predicted the coercive mode
RFC would do so badly. And why I currently predict the basic scalar
type RFC, if voted on, would fail as well.

It comes down to what people want. It became quite clear early on,
that no matter what rule set you choose, there is a non-trivial amount
of people who want something else. This is life.

However, in this case, there are basically 3 camps:

Those that want purely weak types (what we have with ZPP now).
Those that want stronger weak types (similar to what the coercive
mode proposal does, but slightly stricter)
Those that want strict types.

Each of these three camps has a non-trivial amount of members (at
least 20-30%). Personal interactions that I've had suggest to me that
the largest camp is for strong types, but even if it wasn't, it's
still not trivial.

So what does that mean? Well, it means that no single mode proposal
can pass. Because any single mode proposal is 100% guaranteed to
alienate the needs/wants of at least 1, but more likely 2 of those
groups.

The current dual mode proposal is the only one that I've seen that
doesn't alienate groups. It gives the purely weak camp what they want
(and by default too). It gives the strict type camp what they want.
And it lets the stronger-weak-types group choose between the two as
they want/need. Is it a perfect proposal? No. But it works for
everyone, rather than against them.

Zeev mentioned on twitter yesterday that he wants to "at least try and
understand why people are voting no for it and turn it around" with
respect to his coercive proposal. Despite the fact that many people
have said in threads why they voted against it, let me say it again
here, really simply. There are two fundamental reasons people are
voting against it: 1) Backwards Compatibility and 2) It alienates the
needs of a portion of voters. And there's a deeper problem. In trying
to "clean up" the conversions, it partially makes it stricter than
some want (the purely weak group) and doesn't go far enough for those
that want stronger weak types. So it sits as a worst-of-all-worlds.

Bob's pure-weak proposal (which is basically 1/2 of the dual mode RFC)
seems like a great compromise. It's simple, easy to use, easy to
understand, and can be part of a stepping stone to future modes (a
strict mode can always be added later).

But that ignores that it doesn't give 2/3 of the people what they
want/need. It ignores that it actually makes it less likely for
those 2/3 to get what they want/need. Without the support of 2 of the
groups, it's unlikely that anything will ever pass. And a future RFC
to introduce a strict mode (after we have a weak mode) would be
unlikely to pass since it serves no benefit to the weak group.

So what effectively would happen is you'd get at least 1 of the groups
(the strict group) to vote against it. And you'd get at least a few
from the stronger-weak types group to vote against it. Meaning that it
would be hard to get it passed.

Scalar types are a hard problem. Not technically, but politically,
because so many people use PHP in different ways. And everyone thinks
their way is "the one true way". The dual-mode proposal is the only
one on the table that currently addresses the different needs of
different people.

Does that mean that a single-mode compromise is impossible? I wouldn't
use the word impossible, but I certainly would use improbable. We've
been talking about this for years. The chances are quite high that
if a good compromise existed, it would have been found. Instead, every
"compromise" that we've seen simply throws away the needs of an entire
group.

Should we clean up ZPP's parsing rules? Absolutely. "100 apples"
should definitely become an error. But the way to do that is not as a
last-minute change to the language rules. The way we should do that is
with MASSIVE testing to ensure that the breaks are well controlled and
warranted. This is not something that should be done in the 2 days
prior to freeze, but should be planned an executed in a really clear
timeline. Perhaps that's a good goal for 7.1 or 8.0.

But for today, I firmly believe that the Dual-Mode proposal is the
only one that stands a chance of passing. I think it's the best chance
for the language, and it's the only one that tries to unite the
different usages of PHP into a single group, rather than alienating
users.

I respectfully ask Zeev to retract his current proposal as it's
currently failing with 68% of voters voting against it (currently
16:34). Without extending the timeline for 7, there's very little
chance of it passing. So rather than dragging out the entire process
needlessly for 2 more weeks, can we just finally be done with it?

Thanks,

Anthony

11 years ago by Johannes Ott — view source — reply

unread

Thanks for the clear statement, which lights up the fog a little bit for.

Watching out for a scalar typehints feature for round about 10 years
without knowing about this internal list, I always was wondering what
can be so complicated to implement it, because I already evaluated some
different ways how to do this for my thesis.

I already thought about a political reason for that. I'm with you that
your Dual RFC is the right solution to satisfy the needs of all of the
three mentioned groups in my opinion as well.

I would give a clear +1 to it, but I don't have any voting karma yet!

Regards

DerOetzi

11 years ago by Stelian Mocanita — view source — reply

unread

Thanks Anthony for the thorough explanation and your view on the matter,
highly appreciated. I am sure that long-term developers have gone through
both ends of the strong types, either loving their lack while picking up
php for
the first time, either cursing it's lack later on along the way.

As you mentioned you can pretty much do anything in PHP in both small setups
or even "enterprise" - god I hate that word - so it would make sense to
have
something that gives both parties what they want.

Having said this, I am truly hoping we can put an end to all this and have
your
current RFC in and move along.

Regards
Stelian

Thanks for the clear statement, which lights up the fog a little bit for.

Watching out for a scalar typehints feature for round about 10 years
without knowing about this internal list, I always was wondering what
can be so complicated to implement it, because I already evaluated some
different ways how to do this for my thesis.

I already thought about a political reason for that. I'm with you that
your Dual RFC is the right solution to satisfy the needs of all of the
three mentioned groups in my opinion as well.

I would give a clear +1 to it, but I don't have any voting karma yet!

Regards

DerOetzi

11 years ago by Marcio Almada — view source — reply

unread

Hi,

2015-03-13 12:45 GMT-03:00 Anthony Ferrara ircmaxell@gmail.com:

All,
[...]
I respectfully ask Zeev to retract his current proposal as it's
currently failing with 68% of voters voting against it (currently
16:34). Without extending the timeline for 7, there's very little
chance of it passing. So rather than dragging out the entire process
needlessly for 2 more weeks, can we just finally be done with it?

Thanks,

Anthony

--

At the time I'm witting this, the "Coercive Scalar Types" RFC needs 52
"yes" votes to reach minimum ratio. This RFC was well discussed and people
justified their "no" votes quite verbosely on the respective thread. Being
practical, we all know it has no chances to pass.

By keeping this vote running we put in risk all the advancements that are
already so close to be consolidated. Loosing this opportunity would be
damaging for both the major part of the community and the RFC process
itself, IMMO, specially because the dual mode RFC already reached super
majority and the voting would be closed today.

The concurrent RFC, that is now clearly rejected, had its chance and
failed. I agree that dropping the vote for "Coercive Scalar Typehints" is
the logical (even noble) attitude in such context. Please let's not drag
this situation for more two weeks for nothing.

Regards,
Márcio

11 years ago by Leigh — view source — reply

unread

At the time I'm witting this, the "Coercive Scalar Types" RFC needs 52
"yes" votes to reach minimum ratio. This RFC was well discussed and people
justified their "no" votes quite verbosely on the respective thread. Being
practical, we all know it has no chances to pass.

By keeping this vote running we put in risk all the advancements that are
already so close to be consolidated. Loosing this opportunity would be
damaging for both the major part of the community and the RFC process
itself, IMMO, specially because the dual mode RFC already reached super
majority and the voting would be closed today.

The concurrent RFC, that is now clearly rejected, had its chance and
failed. I agree that dropping the vote for "Coercive Scalar Typehints" is
the logical (even noble) attitude in such context. Please let's not drag
this situation for more two weeks for nothing.

Indeed, at this point in time the Coercive RFC is considered harmful,
a lot of damage has already been done, but we can at least try and
mitigate further damage.

Many people who have been coerced (see what I did there?) into voting
for the coercive RFC have voted against the dual-mode RFC out of
principal. Yes for one is No for another, makes sense. How many do you
think will revisit their vote if one RFC is retracted?

So I also urge people to consider this. Do you want scalar type hints
in the language? If there was only the dual-mode RFC, would you vote
for it? If the answer to both of those is Yes, then you should
consider supporting the option that actually stands a chance of
passing.

If you're in the strict camp, and you're voting against because you
don't want to declare strict in every file, there are ways around
this. Don't oppose the RFC simply on this issue alone.

Cheers,

Leigh.

Hi,

2015-03-13 12:45 GMT-03:00 Anthony Ferrara ircmaxell@gmail.com:

All,
[...]
I respectfully ask Zeev to retract his current proposal as it's
currently failing with 68% of voters voting against it (currently
16:34). Without extending the timeline for 7, there's very little
chance of it passing. So rather than dragging out the entire process
needlessly for 2 more weeks, can we just finally be done with it?

Thanks,

Anthony

--

At the time I'm witting this, the "Coercive Scalar Types" RFC needs 52
"yes" votes to reach minimum ratio. This RFC was well discussed and people
justified their "no" votes quite verbosely on the respective thread. Being
practical, we all know it has no chances to pass.

By keeping this vote running we put in risk all the advancements that are
already so close to be consolidated. Loosing this opportunity would be
damaging for both the major part of the community and the RFC process
itself, IMMO, specially because the dual mode RFC already reached super
majority and the voting would be closed today.

The concurrent RFC, that is now clearly rejected, had its chance and
failed. I agree that dropping the vote for "Coercive Scalar Typehints" is
the logical (even noble) attitude in such context. Please let's not drag
this situation for more two weeks for nothing.

Regards,
Márcio

11 years ago by Maciej Sobaczewski — view source — reply

unread

Currently Scalar Type Declarations are going to fall. We have 33 No
votes and I really wonder why there is almost no justification for them.
I know that it's not required, but it is a matter of good taste in whole
voting proces.

I think (and I do really hope) that some of those 33 votes came from
misunderstanding of the proposal. Why don't we try to minify the number
of doubts.

Also, I'd like to ask about the way these accounts are allowed to vote,
according to our rules:

https://people.php.net/user.php?username=olemarkus
https://people.php.net/user.php?username=brianlmoon
https://people.php.net/user.php?username=dom

No Karma makes me feel it's right thing to raise this question. Are they
" Representatives from the PHP community, that will be chosen by those
with php.net SVN accounts"?

Best regards,
Maciej.

W dniu 2015-03-13 o 16:45, Anthony Ferrara pisze:

All,

There's something that I think needs to be said about the now 3 scalar
type proposals. Please bear with me, there's a lot to say here. I'll
try to keep it as brief as I can.

I've been working off-and-on on scalar types for over 3 years. I've
officially proposed 3 proposals and have discussed and played with
many more versions. After I left, Andrea mentioned to me that she
wanted to pick one up. So I helped her. I worked with her for months
on what was ultimately withdrawn
(https://wiki.php.net/rfc/scalar_type_hinting_with_cast). At that
point I resigned to the fact that it wasn't possible to do scalar
types in PHP.

Andrea proved me wrong. When she came up with the dual-mode RFC in
0.3, it was the first proposal that either of us worked on that even
had a shot of passing. She put it up to vote slightly prematurely, but
the votes were pretty clear that it was basically what people wanted,
but with a few minor "issues". When she abandoned it, I picked it up.
Partly because I wanted to see it pass (I think it's the right
proposal), but partly because I didn't want to see her efforts go in
vain by people who didn't even understand the why.

So let me explain what I learned through that experience. Why I chose
to pick the dual mode RFC back up. Why I predicted the coercive mode
RFC would do so badly. And why I currently predict the basic scalar
type RFC, if voted on, would fail as well.

It comes down to what people want. It became quite clear early on,
that no matter what rule set you choose, there is a non-trivial amount
of people who want something else. This is life.

However, in this case, there are basically 3 camps:

Those that want purely weak types (what we have with ZPP now).

Those that want stronger weak types (similar to what the coercive
mode proposal does, but slightly stricter)

Those that want strict types.

Each of these three camps has a non-trivial amount of members (at
least 20-30%). Personal interactions that I've had suggest to me that
the largest camp is for strong types, but even if it wasn't, it's
still not trivial.

So what does that mean? Well, it means that no single mode proposal
can pass. Because any single mode proposal is 100% guaranteed to
alienate the needs/wants of at least 1, but more likely 2 of those
groups.

The current dual mode proposal is the only one that I've seen that
doesn't alienate groups. It gives the purely weak camp what they want
(and by default too). It gives the strict type camp what they want.
And it lets the stronger-weak-types group choose between the two as
they want/need. Is it a perfect proposal? No. But it works for
everyone, rather than against them.

Zeev mentioned on twitter yesterday that he wants to "at least try and
understand why people are voting no for it and turn it around" with
respect to his coercive proposal. Despite the fact that many people
have said in threads why they voted against it, let me say it again
here, really simply. There are two fundamental reasons people are
voting against it: 1) Backwards Compatibility and 2) It alienates the
needs of a portion of voters. And there's a deeper problem. In trying
to "clean up" the conversions, it partially makes it stricter than
some want (the purely weak group) and doesn't go far enough for those
that want stronger weak types. So it sits as a worst-of-all-worlds.

Bob's pure-weak proposal (which is basically 1/2 of the dual mode RFC)
seems like a great compromise. It's simple, easy to use, easy to
understand, and can be part of a stepping stone to future modes (a
strict mode can always be added later).

But that ignores that it doesn't give 2/3 of the people what they
want/need. It ignores that it actually makes it less likely for
those 2/3 to get what they want/need. Without the support of 2 of the
groups, it's unlikely that anything will ever pass. And a future RFC
to introduce a strict mode (after we have a weak mode) would be
unlikely to pass since it serves no benefit to the weak group.

So what effectively would happen is you'd get at least 1 of the groups
(the strict group) to vote against it. And you'd get at least a few
from the stronger-weak types group to vote against it. Meaning that it
would be hard to get it passed.

Scalar types are a hard problem. Not technically, but politically,
because so many people use PHP in different ways. And everyone thinks
their way is "the one true way". The dual-mode proposal is the only
one on the table that currently addresses the different needs of
different people.

Does that mean that a single-mode compromise is impossible? I wouldn't
use the word impossible, but I certainly would use improbable. We've
been talking about this for years. The chances are quite high that
if a good compromise existed, it would have been found. Instead, every
"compromise" that we've seen simply throws away the needs of an entire
group.

Should we clean up ZPP's parsing rules? Absolutely. "100 apples"
should definitely become an error. But the way to do that is not as a
last-minute change to the language rules. The way we should do that is
with MASSIVE testing to ensure that the breaks are well controlled and
warranted. This is not something that should be done in the 2 days
prior to freeze, but should be planned an executed in a really clear
timeline. Perhaps that's a good goal for 7.1 or 8.0.

But for today, I firmly believe that the Dual-Mode proposal is the
only one that stands a chance of passing. I think it's the best chance
for the language, and it's the only one that tries to unite the
different usages of PHP into a single group, rather than alienating
users.

I respectfully ask Zeev to retract his current proposal as it's
currently failing with 68% of voters voting against it (currently
16:34). Without extending the timeline for 7, there's very little
chance of it passing. So rather than dragging out the entire process
needlessly for 2 more weeks, can we just finally be done with it?

Thanks,

Anthony

11 years ago by Benjamin Eberlei — view source — reply

unread

Currently Scalar Type Declarations are going to fall. We have 33 No votes
and I really wonder why there is almost no justification for them. I know
that it's not required, but it is a matter of good taste in whole voting
proces.

I think (and I do really hope) that some of those 33 votes came from
misunderstanding of the proposal. Why don't we try to minify the number of
doubts.

Also, I'd like to ask about the way these accounts are allowed to vote,
according to our rules:

https://people.php.net/user.php?username=olemarkus
https://people.php.net/user.php?username=brianlmoon
https://people.php.net/user.php?username=dom

No Karma makes me feel it's right thing to raise this question. Are they "
Representatives from the PHP community, that will be chosen by those with
php.net SVN accounts"?

Not sure how bringing this up helps anybody, questing wheater any arbitrary
amount of accoutns should actually vote or not.

The voting rights are just how they are bound to participating in any way
to the PHP project.

Best regards,
Maciej.

W dniu 2015-03-13 o 16:45, Anthony Ferrara pisze:

All,

There's something that I think needs to be said about the now 3 scalar
type proposals. Please bear with me, there's a lot to say here. I'll
try to keep it as brief as I can.

I've been working off-and-on on scalar types for over 3 years. I've
officially proposed 3 proposals and have discussed and played with
many more versions. After I left, Andrea mentioned to me that she
wanted to pick one up. So I helped her. I worked with her for months
on what was ultimately withdrawn
(https://wiki.php.net/rfc/scalar_type_hinting_with_cast). At that
point I resigned to the fact that it wasn't possible to do scalar
types in PHP.

Andrea proved me wrong. When she came up with the dual-mode RFC in
0.3, it was the first proposal that either of us worked on that even
had a shot of passing. She put it up to vote slightly prematurely, but
the votes were pretty clear that it was basically what people wanted,
but with a few minor "issues". When she abandoned it, I picked it up.
Partly because I wanted to see it pass (I think it's the right
proposal), but partly because I didn't want to see her efforts go in
vain by people who didn't even understand the why.

So let me explain what I learned through that experience. Why I chose
to pick the dual mode RFC back up. Why I predicted the coercive mode
RFC would do so badly. And why I currently predict the basic scalar
type RFC, if voted on, would fail as well.

It comes down to what people want. It became quite clear early on,
that no matter what rule set you choose, there is a non-trivial amount
of people who want something else. This is life.

However, in this case, there are basically 3 camps:

Those that want purely weak types (what we have with ZPP now).

Those that want stronger weak types (similar to what the coercive
mode proposal does, but slightly stricter)

Those that want strict types.

Each of these three camps has a non-trivial amount of members (at
least 20-30%). Personal interactions that I've had suggest to me that
the largest camp is for strong types, but even if it wasn't, it's
still not trivial.

So what does that mean? Well, it means that no single mode proposal
can pass. Because any single mode proposal is 100% guaranteed to
alienate the needs/wants of at least 1, but more likely 2 of those
groups.

The current dual mode proposal is the only one that I've seen that
doesn't alienate groups. It gives the purely weak camp what they want
(and by default too). It gives the strict type camp what they want.
And it lets the stronger-weak-types group choose between the two as
they want/need. Is it a perfect proposal? No. But it works for
everyone, rather than against them.

Zeev mentioned on twitter yesterday that he wants to "at least try and
understand why people are voting no for it and turn it around" with
respect to his coercive proposal. Despite the fact that many people
have said in threads why they voted against it, let me say it again
here, really simply. There are two fundamental reasons people are
voting against it: 1) Backwards Compatibility and 2) It alienates the
needs of a portion of voters. And there's a deeper problem. In trying
to "clean up" the conversions, it partially makes it stricter than
some want (the purely weak group) and doesn't go far enough for those
that want stronger weak types. So it sits as a worst-of-all-worlds.

Bob's pure-weak proposal (which is basically 1/2 of the dual mode RFC)
seems like a great compromise. It's simple, easy to use, easy to
understand, and can be part of a stepping stone to future modes (a
strict mode can always be added later).

But that ignores that it doesn't give 2/3 of the people what they
want/need. It ignores that it actually makes it less likely for
those 2/3 to get what they want/need. Without the support of 2 of the
groups, it's unlikely that anything will ever pass. And a future RFC
to introduce a strict mode (after we have a weak mode) would be
unlikely to pass since it serves no benefit to the weak group.

So what effectively would happen is you'd get at least 1 of the groups
(the strict group) to vote against it. And you'd get at least a few
from the stronger-weak types group to vote against it. Meaning that it
would be hard to get it passed.

Scalar types are a hard problem. Not technically, but politically,
because so many people use PHP in different ways. And everyone thinks
their way is "the one true way". The dual-mode proposal is the only
one on the table that currently addresses the different needs of
different people.

Does that mean that a single-mode compromise is impossible? I wouldn't
use the word impossible, but I certainly would use improbable. We've
been talking about this for years. The chances are quite high that
if a good compromise existed, it would have been found. Instead, every
"compromise" that we've seen simply throws away the needs of an entire
group.

Should we clean up ZPP's parsing rules? Absolutely. "100 apples"
should definitely become an error. But the way to do that is not as a
last-minute change to the language rules. The way we should do that is
with MASSIVE testing to ensure that the breaks are well controlled and
warranted. This is not something that should be done in the 2 days
prior to freeze, but should be planned an executed in a really clear
timeline. Perhaps that's a good goal for 7.1 or 8.0.

But for today, I firmly believe that the Dual-Mode proposal is the
only one that stands a chance of passing. I think it's the best chance
for the language, and it's the only one that tries to unite the
different usages of PHP into a single group, rather than alienating
users.

I respectfully ask Zeev to retract his current proposal as it's
currently failing with 68% of voters voting against it (currently
16:34). Without extending the timeline for 7, there's very little
chance of it passing. So rather than dragging out the entire process
needlessly for 2 more weeks, can we just finally be done with it?

Thanks,

Anthony

11 years ago by eli@eliw.com — view source — reply

unread

I really don't think that you want us to be going down the
"Republican/Democrat Redistricting" game Maciej, not during an active
vote at least. Attempting to 'help one side win' by deciding that some
people's votes on the side that you are not for ... should just be
discounted.

Is not the way to attempt to 'win' a vote.

Eli

Currently Scalar Type Declarations are going to fall. We have 33 No
votes and I really wonder why there is almost no justification for
them. I know that it's not required, but it is a matter of good taste
in whole voting proces.

I think (and I do really hope) that some of those 33 votes came from
misunderstanding of the proposal. Why don't we try to minify the
number of doubts.

Also, I'd like to ask about the way these accounts are allowed to
vote, according to our rules:

https://people.php.net/user.php?username=olemarkus
https://people.php.net/user.php?username=brianlmoon
https://people.php.net/user.php?username=dom

No Karma makes me feel it's right thing to raise this question. Are
they " Representatives from the PHP community, that will be chosen by
those with php.net SVN accounts"?

Best regards,
Maciej.

--
| Eli White | http://eliw.com/ | Twitter: EliW |

11 years ago by Maciej Sobaczewski — view source — reply

unread

Eli, I don't even try to. However, when the result is tentative, it's
good to be sure that we don't have any incorrect votes.

Yes, I'm in favor of this RFC and I never concealed it, but I'm not
going to discredit any of the voting members. If the final decision will
be negative I'll just get over it and go on. On the other hand, I'm
going to and I will raise my concerns until we have time for that.

W dniu 2015-03-13 o 19:12, Eli pisze:

I really don't think that you want us to be going down the
"Republican/Democrat Redistricting" game Maciej, not during an active
vote at least. Attempting to 'help one side win' by deciding that some
people's votes on the side that you are not for ... should just be
discounted.

Is not the way to attempt to 'win' a vote.

Eli

11 years ago by Jan Ehrhardt — view source — reply

unread

Maciej Sobaczewski in php.internals (Fri, 13 Mar 2015 19:04:30 +0100):

I think (and I do really hope) that some of those 33 votes came from
misunderstanding of the proposal.

Maybe. But on the other hand there are some names in the v0.5 no-camp,
that you would want to be on the yes side in such a controversial issue:
dmitry, xinchen, mike, rasmus, stas and zeev, to name some. There seems
to be a big divide between those and the 65-67% in the yes-camp at the
moment. If Zeev retracts the Coercive RFC at the moment both proposals
may fail.

Anthony's plea for unity is right on target. No one would benefit from a
divided community.

Jan

BTW: ajf's vote is still missing in the v0.5 RFC !?

11 years ago by pajousek@gmail.com — view source — reply

unread

But for today, I firmly believe that the Dual-Mode proposal is the
only one that stands a chance of passing. I think it's the best chance
for the language, and it's the only one that tries to unite the
different usages of PHP into a single group, rather than alienating
users.

Hello,

I see (as a userland developer) these problems with dual mode:

It is a "setting" that changes the language's behavior; I don't
think that it matters whether or not it would be an INI setting or the
declare() one, because both of them are bad.
It does not "unite different usages of PHP into a single group"; it
does exactly the opposite, splitting PHP usage into TWO groups.
Once this dual mode would be introduced to PHP, there would probably
be no way of removing it later without massive BC break, once most
people would realize that it is really awful to have it in the
language.

(There's probably more of them, but these are the biggest issues I
currently have.)

Regards
Pavel Kouril

11 years ago by Philip Sturgeon — view source — reply

unread

Pavel,

But for today, I firmly believe that the Dual-Mode proposal is the
only one that stands a chance of passing. I think it's the best chance
for the language, and it's the only one that tries to unite the
different usages of PHP into a single group, rather than alienating
users.

Hello,

I see (as a userland developer) these problems with dual mode:

It is a "setting" that changes the language's behavior; I don't
think that it matters whether or not it would be an INI setting or the
declare() one, because both of them are bad.

It does not "unite different usages of PHP into a single group"; it
does exactly the opposite, splitting PHP usage into TWO groups.

Once this dual mode would be introduced to PHP, there would probably
be no way of removing it later without massive BC break, once most
people would realize that it is really awful to have it in the
language.

(There's probably more of them, but these are the biggest issues I
currently have.)

Regards
Pavel Kouril

--

Hang on. This is not the time to nitpick things in various RFCs that
have already been answered time and time again.

An ini setting would be insane because taking an app that works on one
machine and putting it on another would completely break the app.
Hello anything using Composer, hello any CMS, hello any system moving
to a new host that doesn't let you change ini settings, or you dont
know how.

A declare statement in the top of the file changing how that file
handles things is hardly a problem, and is exactly how a lot of other
languages do things. Hello JavaScript.

It seems like you didn't read anything now you're just saying "it's
bad" a lot. Please don't do that.

11 years ago by pajousek@gmail.com — view source — reply

unread

Pavel,

But for today, I firmly believe that the Dual-Mode proposal is the
only one that stands a chance of passing. I think it's the best chance
for the language, and it's the only one that tries to unite the
different usages of PHP into a single group, rather than alienating
users.

Hello,

I see (as a userland developer) these problems with dual mode:

It is a "setting" that changes the language's behavior; I don't
think that it matters whether or not it would be an INI setting or the
declare() one, because both of them are bad.

It does not "unite different usages of PHP into a single group"; it
does exactly the opposite, splitting PHP usage into TWO groups.

Once this dual mode would be introduced to PHP, there would probably
be no way of removing it later without massive BC break, once most
people would realize that it is really awful to have it in the
language.

(There's probably more of them, but these are the biggest issues I
currently have.)

Regards
Pavel Kouril

--

Hang on. This is not the time to nitpick things in various RFCs that
have already been answered time and time again.

An ini setting would be insane because taking an app that works on one
machine and putting it on another would completely break the app.
Hello anything using Composer, hello any CMS, hello any system moving
to a new host that doesn't let you change ini settings, or you dont
know how.

A declare statement in the top of the file changing how that file
handles things is hardly a problem, and is exactly how a lot of other
languages do things. Hello JavaScript.

It seems like you didn't read anything now you're just saying "it's
bad" a lot. Please don't do that.

Hello,

there may maybe be some misinterpretation of what I'm saying, but I
read everything from the scalar types discussions in the past 2 or 3
months, actually.

I know ini setting is much much worse than this, but this is imho
still bad - the "intent" is pretty much similiar (aka some directive
that changes how code behaves); I've been saying that I disagree with
this approach ever since the Andrea's first Dual Mode was published as
a RFC and I feel I need to bring it up again.

Regards
Pavel Kouril

11 years ago by Arvids Godjuks — view source — reply

unread

пт, 13 Мар 2015, 23:01, Philip Sturgeon pjsturgeon@gmail.com:

Pavel,

On Fri, Mar 13, 2015 at 4:45 PM, Anthony Ferrara ircmaxell@gmail.com
wrote:

But for today, I firmly believe that the Dual-Mode proposal is the
only one that stands a chance of passing. I think it's the best chance
for the language, and it's the only one that tries to unite the
different usages of PHP into a single group, rather than alienating
users.

Hello,

I see (as a userland developer) these problems with dual mode:

It is a "setting" that changes the language's behavior; I don't
think that it matters whether or not it would be an INI setting or the
declare() one, because both of them are bad.

It does not "unite different usages of PHP into a single group"; it
does exactly the opposite, splitting PHP usage into TWO groups.

Once this dual mode would be introduced to PHP, there would probably
be no way of removing it later without massive BC break, once most
people would realize that it is really awful to have it in the
language.

(There's probably more of them, but these are the biggest issues I
currently have.)

Regards
Pavel Kouril

--

Hang on. This is not the time to nitpick things in various RFCs that
have already been answered time and time again.

An ini setting would be insane because taking an app that works on one
machine and putting it on another would completely break the app.
Hello anything using Composer, hello any CMS, hello any system moving
to a new host that doesn't let you change ini settings, or you dont
know how.

A declare statement in the top of the file changing how that file
handles things is hardly a problem, and is exactly how a lot of other
languages do things. Hello JavaScript.

It seems like you didn't read anything now you're just saying "it's
bad" a lot. Please don't do that.

--

That declare thing with the removal of block-aware declare(){} kills one
of the fundamental optimizations you can do for large PHP projects -
compacting most used files into one single big file and caching it. And you
never had to care what the files are - just splice it all together and let
autoload handle the rare cases. With single declare statement I effectivly
have to scan all the code, remove declare statements and choose a mode
globally. Well, it might work for a small project, but in a big project
with multiple teams or even multiple vendors doing different parts....

At this point I have only swearing words for the proposing persons and
supporters.
It's magic_quotes and register_globals all over again, but this time you
can't fix it with some PHP code.

You really had to fuck it all up for us, the userland developers, didn't
you?

Sorry, but I now question the wisdom and sanity of most new PHP folks.
Because the old once see the danger and vote "no". And everyone just thinks
they act up. Well, you wrong. I will nit be surprised if they just leave
the project for good after this.

11 years ago by Anthony Ferrara — view source — reply

unread

Arvids,

That declare thing with the removal of block-aware declare(){} kills one of
the fundamental optimizations you can do for large PHP projects - compacting
most used files into one single big file and caching it. And you never had
to care what the files are - just splice it all together and let autoload
handle the rare cases. With single declare statement I effectivly have to
scan all the code, remove declare statements and choose a mode globally.
Well, it might work for a small project, but in a big project with multiple
teams or even multiple vendors doing different parts....

http://news.php.net/php.internals/83356 <-- That's why it isn't
supported. I tried. I wanted to. It's just not feasible. If you want
to find a way, go for it. We can then add that mode later. Awesome!

However, if you really want to merge files together, great. Strip out
the strict mode and change everything to weak. It will all still work
100% unless you relied on the exception (which you shouldn't be
doing anyway).

And that's not even mentioning that with opcache the benefits of
merging files together is diminished significantly. But if you want
to, there's still a way.

At this point I have only swearing words for the proposing persons and
supporters.
It's magic_quotes and register_globals all over again, but this time you
can't fix it with some PHP code.

You really had to fuck it all up for us, the userland developers, didn't
you?

Sorry, but I now question the wisdom and sanity of most new PHP folks.
Because the old once see the danger and vote "no". And everyone just thinks
they act up. Well, you wrong. I will nit be surprised if they just leave the
project for good after this.

Please remain respectful. That section was way out of line, and you
really must know that.

Anthony

11 years ago by Benjamin Eberlei — view source — reply

unread

On Sat, Mar 14, 2015 at 12:02 AM, Arvids Godjuks arvids.godjuks@gmail.com
wrote:

пт, 13 Мар 2015, 23:01, Philip Sturgeon pjsturgeon@gmail.com:

Pavel,

On Fri, Mar 13, 2015 at 3:38 PM, Pavel Kouřil pajousek@gmail.com
wrote:

On Fri, Mar 13, 2015 at 4:45 PM, Anthony Ferrara ircmaxell@gmail.com
wrote:

But for today, I firmly believe that the Dual-Mode proposal is the
only one that stands a chance of passing. I think it's the best chance
for the language, and it's the only one that tries to unite the
different usages of PHP into a single group, rather than alienating
users.

Hello,

I see (as a userland developer) these problems with dual mode:

It is a "setting" that changes the language's behavior; I don't
think that it matters whether or not it would be an INI setting or the
declare() one, because both of them are bad.

It does not "unite different usages of PHP into a single group"; it
does exactly the opposite, splitting PHP usage into TWO groups.

Once this dual mode would be introduced to PHP, there would probably
be no way of removing it later without massive BC break, once most
people would realize that it is really awful to have it in the
language.

(There's probably more of them, but these are the biggest issues I
currently have.)

Regards
Pavel Kouril

--

Hang on. This is not the time to nitpick things in various RFCs that
have already been answered time and time again.

An ini setting would be insane because taking an app that works on one
machine and putting it on another would completely break the app.
Hello anything using Composer, hello any CMS, hello any system moving
to a new host that doesn't let you change ini settings, or you dont
know how.

A declare statement in the top of the file changing how that file
handles things is hardly a problem, and is exactly how a lot of other
languages do things. Hello JavaScript.

It seems like you didn't read anything now you're just saying "it's
bad" a lot. Please don't do that.

--

That declare thing with the removal of block-aware declare(){} kills one
of the fundamental optimizations you can do for large PHP projects -
compacting most used files into one single big file and caching it. And you
never had to care what the files are - just splice it all together and let
autoload handle the rare cases. With single declare statement I effectivly
have to scan all the code, remove declare statements and choose a mode
globally. Well, it might work for a small project, but in a big project
with multiple teams or even multiple vendors doing different parts....

The same is true for namespaces, but Symfony for example works around it by
introducing block syntax.
You can just remove the declares, during concatenation, or move a single
strict to the top.

Also this is not a fundamental optimization (I'd argue never has been)
anymore since opcache is in core of PHP since 5.5

At this point I have only swearing words for the proposing persons and
supporters.
It's magic_quotes and register_globals all over again, but this time you
can't fix it with some PHP code.

You really had to fuck it all up for us, the userland developers, didn't
you?

Sorry, but I now question the wisdom and sanity of most new PHP folks.
Because the old once see the danger and vote "no". And everyone just thinks
they act up. Well, you wrong. I will nit be surprised if they just leave
the project for good after this.

This list gets pretty intense, but this kind of swearing and attack on
persons is certainly not acceptable in my book.

Like every feature, this is optional.

11 years ago by Arvids Godjuks — view source — reply

unread

Opcode caches just cache the compiled code - you still need to load the
code into the engine, do checks for file modifications and other stuff.

Yes, if you are a badass and have full controll, all that can be solved.
Reality, however, is one big f***up. I had to fix a lot of weird stuff,
including the cases where there was some kind of opcode cache and it still
was horrible. Or shared enviroment. Or just bad code. You havent seen
FTP/SFTP project deployment in last few years? I envy you. You work for
godly clients. Or it's just that you are a rockstar in a rockstar friendly
company with resources and will to do things right. But most of us a far
lower in the food chain. We have to deal with things that would give you
nightmares.

Or take most of Open Source PHP code - besides a few high quality projects
like Symfony and the bunch, it's bad. And I know one instanse of an Open
Source project with PHP part that will go full retard mode with strict
typehints no matter the cost or consiquences. Probably will end up killing
the company behind it in the long run.

There is one thing that you learn when you actually go beyound the coding:
never ever give user a choise - he doesn't know what he wants anyway. He
thinks he needs one thing, in reality tests show absolutelly different
stuff. You need to make a decision select a way you wana do it. It newer
works out with choises - people always make a mess.

сб, 14 Мар 2015, 1:11, Benjamin Eberlei kontakt@beberlei.de:

On Sat, Mar 14, 2015 at 12:02 AM, Arvids Godjuks <arvids.godjuks@gmail.com

wrote:

пт, 13 Мар 2015, 23:01, Philip Sturgeon pjsturgeon@gmail.com:

Pavel,

On Fri, Mar 13, 2015 at 3:38 PM, Pavel Kouřil pajousek@gmail.com
wrote:

On Fri, Mar 13, 2015 at 4:45 PM, Anthony Ferrara <ircmaxell@gmail.com

wrote:

But for today, I firmly believe that the Dual-Mode proposal is the
only one that stands a chance of passing. I think it's the best
chance
for the language, and it's the only one that tries to unite the
different usages of PHP into a single group, rather than alienating
users.

Hello,

I see (as a userland developer) these problems with dual mode:

It is a "setting" that changes the language's behavior; I don't
think that it matters whether or not it would be an INI setting or the
declare() one, because both of them are bad.

It does not "unite different usages of PHP into a single group"; it
does exactly the opposite, splitting PHP usage into TWO groups.

Once this dual mode would be introduced to PHP, there would probably
be no way of removing it later without massive BC break, once most
people would realize that it is really awful to have it in the
language.

(There's probably more of them, but these are the biggest issues I
currently have.)

Regards
Pavel Kouril

--

Hang on. This is not the time to nitpick things in various RFCs that
have already been answered time and time again.

An ini setting would be insane because taking an app that works on one
machine and putting it on another would completely break the app.
Hello anything using Composer, hello any CMS, hello any system moving
to a new host that doesn't let you change ini settings, or you dont
know how.

A declare statement in the top of the file changing how that file
handles things is hardly a problem, and is exactly how a lot of other
languages do things. Hello JavaScript.

It seems like you didn't read anything now you're just saying "it's
bad" a lot. Please don't do that.

--

That declare thing with the removal of block-aware declare(){} kills one
of the fundamental optimizations you can do for large PHP projects -
compacting most used files into one single big file and caching it. And
you
never had to care what the files are - just splice it all together and
let
autoload handle the rare cases. With single declare statement I effectivly
have to scan all the code, remove declare statements and choose a mode
globally. Well, it might work for a small project, but in a big project
with multiple teams or even multiple vendors doing different parts....

The same is true for namespaces, but Symfony for example works around it
by introducing block syntax.
You can just remove the declares, during concatenation, or move a single
strict to the top.

Also this is not a fundamental optimization (I'd argue never has been)
anymore since opcache is in core of PHP since 5.5

At this point I have only swearing words for the proposing persons and
supporters.
It's magic_quotes and register_globals all over again, but this time you
can't fix it with some PHP code.

You really had to fuck it all up for us, the userland developers, didn't
you?

Sorry, but I now question the wisdom and sanity of most new PHP folks.
Because the old once see the danger and vote "no". And everyone just
thinks
they act up. Well, you wrong. I will nit be surprised if they just leave
the project for good after this.

This list gets pretty intense, but this kind of swearing and attack on
persons is certainly not acceptable in my book.

Like every feature, this is optional.

11 years ago by Arvids Godjuks — view source — reply

unread

And actually, I would plea for a moment of sanity right now.

As far as i'm concerned - the RM for the 7.0 had to step in a long time ago
and said "guys, I do not accept any typehint proposals into the 7.0
release, work it out and come back for 7.1".
Because if this would be a commercial development before a release -
feature would be scrapped and re-sheduled for later release.
Why? Because the clusterf**k happened at RFC level already, the development
itself is going to be haisty considering the timeline and definetly being
bombarded by the protesters, countless critisism and so on. It is going to
affect the projects. And that is a bad thing. Look past the damn typehint
RFC's and just try to asses the big picture. Right now it's a tunnel vision
for many on the list.

сб, 14 Мар 2015, 1:29, Arvids Godjuks arvids.godjuks@gmail.com:

Opcode caches just cache the compiled code - you still need to load the
code into the engine, do checks for file modifications and other stuff.

Yes, if you are a badass and have full controll, all that can be solved.
Reality, however, is one big f***up. I had to fix a lot of weird stuff,
including the cases where there was some kind of opcode cache and it still
was horrible. Or shared enviroment. Or just bad code. You havent seen
FTP/SFTP project deployment in last few years? I envy you. You work for
godly clients. Or it's just that you are a rockstar in a rockstar friendly
company with resources and will to do things right. But most of us a far
lower in the food chain. We have to deal with things that would give you
nightmares.

Or take most of Open Source PHP code - besides a few high quality projects
like Symfony and the bunch, it's bad. And I know one instanse of an Open
Source project with PHP part that will go full retard mode with strict
typehints no matter the cost or consiquences. Probably will end up killing
the company behind it in the long run.

There is one thing that you learn when you actually go beyound the coding:
never ever give user a choise - he doesn't know what he wants anyway. He
thinks he needs one thing, in reality tests show absolutelly different
stuff. You need to make a decision select a way you wana do it. It newer
works out with choises - people always make a mess.

сб, 14 Мар 2015, 1:11, Benjamin Eberlei kontakt@beberlei.de:

On Sat, Mar 14, 2015 at 12:02 AM, Arvids Godjuks <arvids.godjuks@gmail.com

wrote:

пт, 13 Мар 2015, 23:01, Philip Sturgeon pjsturgeon@gmail.com:

Pavel,

On Fri, Mar 13, 2015 at 3:38 PM, Pavel Kouřil pajousek@gmail.com
wrote:

On Fri, Mar 13, 2015 at 4:45 PM, Anthony Ferrara <
ircmaxell@gmail.com>
wrote:

But for today, I firmly believe that the Dual-Mode proposal is the
only one that stands a chance of passing. I think it's the best
chance
for the language, and it's the only one that tries to unite the
different usages of PHP into a single group, rather than alienating
users.

Hello,

I see (as a userland developer) these problems with dual mode:

It is a "setting" that changes the language's behavior; I don't
think that it matters whether or not it would be an INI setting or
the
declare() one, because both of them are bad.

It does not "unite different usages of PHP into a single group"; it
does exactly the opposite, splitting PHP usage into TWO groups.

Once this dual mode would be introduced to PHP, there would
probably
be no way of removing it later without massive BC break, once most
people would realize that it is really awful to have it in the
language.

(There's probably more of them, but these are the biggest issues I
currently have.)

Regards
Pavel Kouril

--

Hang on. This is not the time to nitpick things in various RFCs that
have already been answered time and time again.

An ini setting would be insane because taking an app that works on one
machine and putting it on another would completely break the app.
Hello anything using Composer, hello any CMS, hello any system moving
to a new host that doesn't let you change ini settings, or you dont
know how.

A declare statement in the top of the file changing how that file
handles things is hardly a problem, and is exactly how a lot of other
languages do things. Hello JavaScript.

It seems like you didn't read anything now you're just saying "it's
bad" a lot. Please don't do that.

--

That declare thing with the removal of block-aware declare(){} kills
one
of the fundamental optimizations you can do for large PHP projects -
compacting most used files into one single big file and caching it. And
you
never had to care what the files are - just splice it all together and
let
autoload handle the rare cases. With single declare statement I
effectivly
have to scan all the code, remove declare statements and choose a mode
globally. Well, it might work for a small project, but in a big project
with multiple teams or even multiple vendors doing different parts....

The same is true for namespaces, but Symfony for example works around it
by introducing block syntax.
You can just remove the declares, during concatenation, or move a single
strict to the top.

Also this is not a fundamental optimization (I'd argue never has been)
anymore since opcache is in core of PHP since 5.5

At this point I have only swearing words for the proposing persons and
supporters.
It's magic_quotes and register_globals all over again, but this time you
can't fix it with some PHP code.

You really had to fuck it all up for us, the userland developers, didn't
you?

Sorry, but I now question the wisdom and sanity of most new PHP folks.
Because the old once see the danger and vote "no". And everyone just
thinks
they act up. Well, you wrong. I will nit be surprised if they just leave
the project for good after this.

This list gets pretty intense, but this kind of swearing and attack on
persons is certainly not acceptable in my book.

Like every feature, this is optional.

11 years ago by Lester Caine — view source — reply

unread

And actually, I would plea for a moment of sanity right now.

As far as i'm concerned - the RM for the 7.0 had to step in a long time ago
and said "guys, I do not accept any typehint proposals into the 7.0
release, work it out and come back for 7.1".
Because if this would be a commercial development before a release -
feature would be scrapped and re-sheduled for later release.
Why? Because the clusterf**k happened at RFC level already, the development
itself is going to be haisty considering the timeline and definetly being
bombarded by the protesters, countless critisism and so on. It is going to
affect the projects. And that is a bad thing. Look past the damn typehint
RFC's and just try to asses the big picture. Right now it's a tunnel vision
for many on the list.

Seconded ...
There are more important things to get right, so perhaps just protecting
the hooks for type hints is the best that can be fully supported in PHP7 ?
Lets simply get the ground rules on naming conventions and what is
reserved and the like to start the path to bigger things later?

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

11 years ago by Lester Caine — view source — reply

unread

Lets simply get the ground rules on naming conventions and what is
reserved and the like to start the path to bigger things later?

I'll ask yet again a question that I keep asking but not seeing anybody
explaining. Just what is being added which PHP5 will actually baulk at?
I've been assuming 'the type hints' and that it is adding these which
will make a current library unusable with PHP5 systems? All of the
discussion on just HOW the type hints are handled is secondary to the
basic breaking of the code base? Once a third party has added type hints
we have to handle the results, which may be different depending on how
the 'user' of type hint expects it to be interpreted? Weak or Strict
will fail in different ways? But of more interest, just what happens if
I pick up a library that has been 'improved' by the inclusion of strict
types but I'm still working with no typing at all? Or rather legacy type
checking as part of the code base.

The code base I will be running myself with PHP7 is PHP5.4 with E_STRICT
etc. clean code. That is what the test bed is comparing and with what
has been added so far the code simply works, and I expect THAT to be the
case but I keep seeing things which suggest I will HAVE to make changes
to the PHP5.4 code for it to run clean on PHP7 by the time we get to RC
stage?

--
Lester Caine - G8HFL

11 years ago by Dan Ackroyd — view source — reply

unread

Just what is being added which PHP5 will actually baulk at?
The code base I will be running myself with PHP7 is PHP5.4 with E_STRICT
etc. clean code.

For the RFC https://wiki.php.net/rfc/scalar_type_hints_v5 that is on
the edge of passing there will be no effects on BC for code, except
for the fact that int/string etc are now reserved words.

There may be other issues upgrading to 7 caused by other RFCs - but
that scalar type hints proposal does not cause any issues.

I'll ask yet again a question that I keep asking but not seeing anybody
explaining.

Perhaps if you sent fewer emails to the internals list, people would
be more likely to read and respond to the emails you do send?

cheers
Dan

11 years ago by padraic.brady@gmail.com — view source — reply

unread

Hi,

And actually, I would plea for a moment of sanity right now.

As far as i'm concerned - the RM for the 7.0 had to step in a long time ago
and said "guys, I do not accept any typehint proposals into the 7.0
release, work it out and come back for 7.1".
Because if this would be a commercial development before a release -
feature would be scrapped and re-sheduled for later release.
Why? Because the clusterf**k happened at RFC level already, the development
itself is going to be haisty considering the timeline and definetly being
bombarded by the protesters, countless critisism and so on. It is going to
affect the projects. And that is a bad thing. Look past the damn typehint
RFC's and just try to asses the big picture. Right now it's a tunnel vision
for many on the list.

This has been under discussion for a really long time and putting it
off is unlikely to substantially change the outcome. The current RFCs
went to vote within the allowed timeline for PHP7. What you are
basically saying is that the entire PHP 7 timeline is flawed. If
that's the case then you should be arguing for the PHP7 timing to be
changed, if you feel that any RFC will need additional development
time, not for the typehinting RFCs to all be withdrawn.

Paddy

--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com

11 years ago by Derick Rethans — view source — reply

unread

At this point I have only swearing words for the proposing persons and
supporters.

Certainly that is going to help?

It's magic_quotes and register_globals all over again, but this time
you can't fix it with some PHP code.

It is not even close to equivalent. As those options are php.ini
settings. There is nothing, absolutely nothing, that will change if
you, as an author of a PHP file, does not use typehints in that file.

If a dev turns a file that he or she wrote into strict mode, then that
only counts for that specific file. If you take over some code, then you
can remove the declare line. none of those things you'd be able to do
with ini settings. So don't shout out that nonsense FUD.

You really had to fuck it all up for us, the userland developers,
didn't you?

Sorry, but I now question the wisdom and sanity of most new PHP folks.
Because the old once see the danger and vote "no". And everyone just thinks
they act up. Well, you wrong. I will nit be surprised if they just leave
the project for good after this.

Yes, because of people like you swearing at them.

cheers,
Derick

11 years ago by Peter van Fessem — view source — reply

unread

It's magic_quotes and register_globals all over again, but this time
you can't fix it with some PHP code.

It is not even close to equivalent. As those options are php.ini
settings. There is nothing, absolutely nothing, that will change if
you, as an author of a PHP file, does not use typehints in that file.

If a dev turns a file that he or she wrote into strict mode, then that
only counts for that specific file. If you take over some code, then you
can remove the declare line. none of those things you'd be able to do
with ini settings. So don't shout out that nonsense FUD.

It's equivalent to an ini setting in that it changes the behavior of the
code based on something that is declared elsewhere. Obviously a declare
statement in the top of the file is a lot better than an ini setting,
but I think the principle is the same.

I prefer consistency over choice. I don't think it's that important that
it matches my wishes/requirements exactly, because it's never going to;
but if a switch is going to be implemented, I'm going to have to use
both depending on who I work with/for, and that seems a lot more
annoying than whatever the type system ends up being.

I would strongly prefer a type system that matches the current type
conversion rules, and slowly 'strengthen' these together, over the
next few major releases to something that matches the weak type system
proposals.

Somewhat unrelated: I don't really buy the javascript strict mode
comparison. Strict mode was added to differentiate between an 'old' and
a 'new' system, but here two new modes are added in one go.

Just my 2 cents.

Regards,
Peter

11 years ago by Dennis Birkholz — view source — reply

unread

Hi together,

Am 14.03.2015 um 14:37 schrieb Peter van Fessem:

If a dev turns a file that he or she wrote into strict mode, then that
only counts for that specific file. If you take over some code, then you
can remove the declare line. none of those things you'd be able to do
with ini settings. So don't shout out that nonsense FUD.

It's equivalent to an ini setting in that it changes the behavior of the
code based on something that is declared elsewhere. Obviously a declare
statement in the top of the file is a lot better than an ini setting,
but I think the principle is the same.

that is simply not true. The principle is not the same. The principle is
roughly the same as with namespaces. If you are unsure, got to the top
of the file, finished. Ini-Settings are runtime-dependent so there is no
way to find out what the ini-setting will be beforehand.

I think nobody will argue that namespaces are to complicated because you
can define the current namespace at the top of a file which than changes
the behavior of the file completely (which it does, somehow, by the way).

Greets
Dennis

11 years ago by Peter van Fessem — view source — reply

unread

Hi together,

Am 14.03.2015 um 14:37 schrieb Peter van Fessem:

If a dev turns a file that he or she wrote into strict mode, then that
only counts for that specific file. If you take over some code, then you
can remove the declare line. none of those things you'd be able to do
with ini settings. So don't shout out that nonsense FUD.

It's equivalent to an ini setting in that it changes the behavior of the
code based on something that is declared elsewhere. Obviously a declare
statement in the top of the file is a lot better than an ini setting,
but I think the principle is the same.

that is simply not true. The principle is not the same. The principle is
roughly the same as with namespaces. If you are unsure, got to the top
of the file, finished. Ini-Settings are runtime-dependent so there is no
way to find out what the ini-setting will be beforehand.

I don't think we disagree on this. I was only trying to say that both
ini settings and declare statements influence behavior of other code,
and that in both cases you have to put some effort into looking up the
current value, but that is where the comparison ends.

I think nobody will argue that namespaces are to complicated because you
can define the current namespace at the top of a file which than changes
the behavior of the file completely (which it does, somehow, by the way).

I'd never argue that namespaces are complicated, but they, like every
language feature, add a non zero complication to the language, whether
you would use them yourself or not.

Looking at the top of the file isn't a massive problem, but it is a
small one. If I didn't see the value in namespaces, I'd prefer not to
have them in the language at all (but I do, so I don't).

I'm arguing against statements like: "Well if you don't like strict
mode, don't use it.". It's not that simple. The fact that it exists adds
a cost.

Greets
Dennis

Thanks,
Peter

11 years ago by Larry Garfield — view source — reply

unread

At this point I have only swearing words for the proposing persons and
supporters.
It's magic_quotes and register_globals all over again, but this time you
can't fix it with some PHP code.

You really had to fuck it all up for us, the userland developers, didn't
you?

Sorry, but I now question the wisdom and sanity of most new PHP folks.
Because the old once see the danger and vote "no". And everyone just thinks
they act up. Well, you wrong. I will nit be surprised if they just leave
the project for good after this.

If you're going to behave this way in public, please just leave the
project for good. It will be good for the project.

--Larry Garfield

11 years ago by Philip Sturgeon — view source — reply

unread

On Fri, Mar 13, 2015 at 7:02 PM, Arvids Godjuks
arvids.godjuks@gmail.com wrote:

пт, 13 Мар 2015, 23:01, Philip Sturgeon pjsturgeon@gmail.com:

Pavel,

On Fri, Mar 13, 2015 at 4:45 PM, Anthony Ferrara ircmaxell@gmail.com
wrote:

But for today, I firmly believe that the Dual-Mode proposal is the
only one that stands a chance of passing. I think it's the best chance
for the language, and it's the only one that tries to unite the
different usages of PHP into a single group, rather than alienating
users.

Hello,

I see (as a userland developer) these problems with dual mode:

It is a "setting" that changes the language's behavior; I don't
think that it matters whether or not it would be an INI setting or the
declare() one, because both of them are bad.

It does not "unite different usages of PHP into a single group"; it
does exactly the opposite, splitting PHP usage into TWO groups.

Once this dual mode would be introduced to PHP, there would probably
be no way of removing it later without massive BC break, once most
people would realize that it is really awful to have it in the
language.

(There's probably more of them, but these are the biggest issues I
currently have.)

Regards
Pavel Kouril

--

Hang on. This is not the time to nitpick things in various RFCs that
have already been answered time and time again.

An ini setting would be insane because taking an app that works on one
machine and putting it on another would completely break the app.
Hello anything using Composer, hello any CMS, hello any system moving
to a new host that doesn't let you change ini settings, or you dont
know how.

A declare statement in the top of the file changing how that file
handles things is hardly a problem, and is exactly how a lot of other
languages do things. Hello JavaScript.

It seems like you didn't read anything now you're just saying "it's
bad" a lot. Please don't do that.

--

That declare thing with the removal of block-aware declare(){} kills one of
the fundamental optimizations you can do for large PHP projects - compacting
most used files into one single big file and caching it. And you never had
to care what the files are - just splice it all together and let autoload
handle the rare cases. With single declare statement I effectivly have to
scan all the code, remove declare statements and choose a mode globally.
Well, it might work for a small project, but in a big project with multiple
teams or even multiple vendors doing different parts....

At this point I have only swearing words for the proposing persons and
supporters.
It's magic_quotes and register_globals all over again, but this time you
can't fix it with some PHP code.

You really had to fuck it all up for us, the userland developers, didn't
you?

Sorry, but I now question the wisdom and sanity of most new PHP folks.
Because the old once see the danger and vote "no". And everyone just thinks
they act up. Well, you wrong. I will nit be surprised if they just leave the
project for good after this.

Wow, that's a lot of rage over nothing. Here, I got you a gift:

foreach (new DirectoryIterator('./src/*/.php') as $fileInfo) {
$fileContents = file_get_contents($fileInfo->getFilename());

if (strpos($fileContents, 'declare(strict_types=1') !== 0) {
  $fileContents = str_replace("declare(strict_types", "#

declare(strict_types", $fileContents);
file_put_contents('./compiled/weak.php', $fileContents, FILE_APPEND);
} else {
file_put_contents('./compiled/strict.php', $fileContents, FILE_APPEND);
}
}

Tadaaaaaaa.

Phil Sturgeon. Problem solver. Fixer of the bad day. Userland Ninjitsu. :)

11 years ago by Philip Sturgeon — view source — reply

unread

On Fri, Mar 13, 2015 at 7:02 PM, Arvids Godjuks
arvids.godjuks@gmail.com wrote:

пт, 13 Мар 2015, 23:01, Philip Sturgeon pjsturgeon@gmail.com:

Pavel,

On Fri, Mar 13, 2015 at 4:45 PM, Anthony Ferrara ircmaxell@gmail.com
wrote:

But for today, I firmly believe that the Dual-Mode proposal is the
only one that stands a chance of passing. I think it's the best chance
for the language, and it's the only one that tries to unite the
different usages of PHP into a single group, rather than alienating
users.

Hello,

I see (as a userland developer) these problems with dual mode:

It is a "setting" that changes the language's behavior; I don't
think that it matters whether or not it would be an INI setting or the
declare() one, because both of them are bad.

It does not "unite different usages of PHP into a single group"; it
does exactly the opposite, splitting PHP usage into TWO groups.

Once this dual mode would be introduced to PHP, there would probably
be no way of removing it later without massive BC break, once most
people would realize that it is really awful to have it in the
language.

(There's probably more of them, but these are the biggest issues I
currently have.)

Regards
Pavel Kouril

--

Hang on. This is not the time to nitpick things in various RFCs that
have already been answered time and time again.

An ini setting would be insane because taking an app that works on one
machine and putting it on another would completely break the app.
Hello anything using Composer, hello any CMS, hello any system moving
to a new host that doesn't let you change ini settings, or you dont
know how.

A declare statement in the top of the file changing how that file
handles things is hardly a problem, and is exactly how a lot of other
languages do things. Hello JavaScript.

It seems like you didn't read anything now you're just saying "it's
bad" a lot. Please don't do that.

--

That declare thing with the removal of block-aware declare(){} kills one of
the fundamental optimizations you can do for large PHP projects - compacting
most used files into one single big file and caching it. And you never had
to care what the files are - just splice it all together and let autoload
handle the rare cases. With single declare statement I effectivly have to
scan all the code, remove declare statements and choose a mode globally.
Well, it might work for a small project, but in a big project with multiple
teams or even multiple vendors doing different parts....

At this point I have only swearing words for the proposing persons and
supporters.
It's magic_quotes and register_globals all over again, but this time you
can't fix it with some PHP code.

You really had to fuck it all up for us, the userland developers, didn't
you?

Sorry, but I now question the wisdom and sanity of most new PHP folks.
Because the old once see the danger and vote "no". And everyone just thinks
they act up. Well, you wrong. I will nit be surprised if they just leave the
project for good after this.

Wow, that's a lot of rage over nothing. Here, I got you a gift:

foreach (new DirectoryIterator('./src/*/.php') as $fileInfo) {
$fileContents = file_get_contents($fileInfo->getFilename());
if (strpos($fileContents, 'declare(strict_types=1') !== 0) {
  $fileContents = str_replace("declare(strict_types", "#
declare(strict_types", $fileContents);
file_put_contents('./compiled/weak.php', $fileContents, FILE_APPEND);
} else {
file_put_contents('./compiled/strict.php', $fileContents, FILE_APPEND);
}
}

Tadaaaaaaa.

Phil Sturgeon. Problem solver. Fixer of the bad day. Userland Ninjitsu. :)

I would like to appologize for my previous email. ..

It contained quite a serious oversight.

if (strpos($fileContents, 'declare(strict_types=1') !== true) {

That's better.

11 years ago by Christoph Becker — view source — reply

unread

Philip Sturgeon wrote:

On Fri, Mar 13, 2015 at 7:02 PM, Arvids Godjuks
arvids.godjuks@gmail.com wrote:

пт, 13 Мар 2015, 23:01, Philip Sturgeon pjsturgeon@gmail.com:

Pavel,

On Fri, Mar 13, 2015 at 4:45 PM, Anthony Ferrara ircmaxell@gmail.com
wrote:

But for today, I firmly believe that the Dual-Mode proposal is the
only one that stands a chance of passing. I think it's the best chance
for the language, and it's the only one that tries to unite the
different usages of PHP into a single group, rather than alienating
users.

Hello,

I see (as a userland developer) these problems with dual mode:

It is a "setting" that changes the language's behavior; I don't
think that it matters whether or not it would be an INI setting or the
declare() one, because both of them are bad.

It does not "unite different usages of PHP into a single group"; it
does exactly the opposite, splitting PHP usage into TWO groups.

Once this dual mode would be introduced to PHP, there would probably
be no way of removing it later without massive BC break, once most
people would realize that it is really awful to have it in the
language.

(There's probably more of them, but these are the biggest issues I
currently have.)

Regards
Pavel Kouril

--

Hang on. This is not the time to nitpick things in various RFCs that
have already been answered time and time again.

An ini setting would be insane because taking an app that works on one
machine and putting it on another would completely break the app.
Hello anything using Composer, hello any CMS, hello any system moving
to a new host that doesn't let you change ini settings, or you dont
know how.

A declare statement in the top of the file changing how that file
handles things is hardly a problem, and is exactly how a lot of other
languages do things. Hello JavaScript.

It seems like you didn't read anything now you're just saying "it's
bad" a lot. Please don't do that.

--

That declare thing with the removal of block-aware declare(){} kills one of
the fundamental optimizations you can do for large PHP projects - compacting
most used files into one single big file and caching it. And you never had
to care what the files are - just splice it all together and let autoload
handle the rare cases. With single declare statement I effectivly have to
scan all the code, remove declare statements and choose a mode globally.
Well, it might work for a small project, but in a big project with multiple
teams or even multiple vendors doing different parts....

At this point I have only swearing words for the proposing persons and
supporters.
It's magic_quotes and register_globals all over again, but this time you
can't fix it with some PHP code.

You really had to fuck it all up for us, the userland developers, didn't
you?

Sorry, but I now question the wisdom and sanity of most new PHP folks.
Because the old once see the danger and vote "no". And everyone just thinks
they act up. Well, you wrong. I will nit be surprised if they just leave the
project for good after this.

Wow, that's a lot of rage over nothing. Here, I got you a gift:

foreach (new DirectoryIterator('./src/*/.php') as $fileInfo) {
$fileContents = file_get_contents($fileInfo->getFilename());
if (strpos($fileContents, 'declare(strict_types=1') !== 0) {
  $fileContents = str_replace("declare(strict_types", "#
declare(strict_types", $fileContents);
file_put_contents('./compiled/weak.php', $fileContents, FILE_APPEND);
} else {
file_put_contents('./compiled/strict.php', $fileContents, FILE_APPEND);
}
}

Tadaaaaaaa.

Phil Sturgeon. Problem solver. Fixer of the bad day. Userland Ninjitsu. :)
I would like to appologize for my previous email. ..

It contained quite a serious oversight.
if (strpos($fileContents, 'declare(strict_types=1') !== true) {
That's better.

Wouldn't the condition be always true in this case? Testing for ===
false seems to be more appropriate.

--
Christoph M. Becker

11 years ago by Yasuo Ohgaki — view source — reply

unread

Hi Anthony and Zeev,

On Sat, Mar 14, 2015 at 12:45 AM, Anthony Ferrara ircmaxell@gmail.com
wrote:

There's something that I think needs to be said about the now 3 scalar
type proposals. Please bear with me, there's a lot to say here. I'll
try to keep it as brief as I can.

I've been working off-and-on on scalar types for over 3 years. I've
officially proposed 3 proposals and have discussed and played with
many more versions. After I left, Andrea mentioned to me that she
wanted to pick one up. So I helped her. I worked with her for months
on what was ultimately withdrawn
(https://wiki.php.net/rfc/scalar_type_hinting_with_cast). At that
point I resigned to the fact that it wasn't possible to do scalar
types in PHP.

Andrea proved me wrong. When she came up with the dual-mode RFC in
0.3, it was the first proposal that either of us worked on that even
had a shot of passing. She put it up to vote slightly prematurely, but
the votes were pretty clear that it was basically what people wanted,
but with a few minor "issues". When she abandoned it, I picked it up.
Partly because I wanted to see it pass (I think it's the right
proposal), but partly because I didn't want to see her efforts go in
vain by people who didn't even understand the why.

So let me explain what I learned through that experience. Why I chose
to pick the dual mode RFC back up. Why I predicted the coercive mode
RFC would do so badly. And why I currently predict the basic scalar
type RFC, if voted on, would fail as well.

It comes down to what people want. It became quite clear early on,
that no matter what rule set you choose, there is a non-trivial amount
of people who want something else. This is life.

However, in this case, there are basically 3 camps:

Those that want purely weak types (what we have with ZPP now).

Those that want stronger weak types (similar to what the coercive
mode proposal does, but slightly stricter)

Those that want strict types.

Each of these three camps has a non-trivial amount of members (at
least 20-30%). Personal interactions that I've had suggest to me that
the largest camp is for strong types, but even if it wasn't, it's
still not trivial.

So what does that mean? Well, it means that no single mode proposal
can pass. Because any single mode proposal is 100% guaranteed to
alienate the needs/wants of at least 1, but more likely 2 of those
groups.

The current dual mode proposal is the only one that I've seen that
doesn't alienate groups. It gives the purely weak camp what they want
(and by default too). It gives the strict type camp what they want.
And it lets the stronger-weak-types group choose between the two as
they want/need. Is it a perfect proposal? No. But it works for
everyone, rather than against them.

Zeev mentioned on twitter yesterday that he wants to "at least try and
understand why people are voting no for it and turn it around" with
respect to his coercive proposal. Despite the fact that many people
have said in threads why they voted against it, let me say it again
here, really simply. There are two fundamental reasons people are
voting against it: 1) Backwards Compatibility and 2) It alienates the
needs of a portion of voters. And there's a deeper problem. In trying
to "clean up" the conversions, it partially makes it stricter than
some want (the purely weak group) and doesn't go far enough for those
that want stronger weak types. So it sits as a worst-of-all-worlds.

Bob's pure-weak proposal (which is basically 1/2 of the dual mode RFC)
seems like a great compromise. It's simple, easy to use, easy to
understand, and can be part of a stepping stone to future modes (a
strict mode can always be added later).

But that ignores that it doesn't give 2/3 of the people what they
want/need. It ignores that it actually makes it less likely for
those 2/3 to get what they want/need. Without the support of 2 of the
groups, it's unlikely that anything will ever pass. And a future RFC
to introduce a strict mode (after we have a weak mode) would be
unlikely to pass since it serves no benefit to the weak group.

So what effectively would happen is you'd get at least 1 of the groups
(the strict group) to vote against it. And you'd get at least a few
from the stronger-weak types group to vote against it. Meaning that it
would be hard to get it passed.

Scalar types are a hard problem. Not technically, but politically,
because so many people use PHP in different ways. And everyone thinks
their way is "the one true way". The dual-mode proposal is the only
one on the table that currently addresses the different needs of
different people.

Does that mean that a single-mode compromise is impossible? I wouldn't
use the word impossible, but I certainly would use improbable. We've
been talking about this for years. The chances are quite high that
if a good compromise existed, it would have been found. Instead, every
"compromise" that we've seen simply throws away the needs of an entire
group.

Should we clean up ZPP's parsing rules? Absolutely. "100 apples"
should definitely become an error. But the way to do that is not as a
last-minute change to the language rules. The way we should do that is
with MASSIVE testing to ensure that the breaks are well controlled and
warranted. This is not something that should be done in the 2 days
prior to freeze, but should be planned an executed in a really clear
timeline. Perhaps that's a good goal for 7.1 or 8.0.

But for today, I firmly believe that the Dual-Mode proposal is the
only one that stands a chance of passing. I think it's the best chance
for the language, and it's the only one that tries to unite the
different usages of PHP into a single group, rather than alienating
users.

I respectfully ask Zeev to retract his current proposal as it's
currently failing with 68% of voters voting against it (currently
16:34). Without extending the timeline for 7, there's very little
chance of it passing. So rather than dragging out the entire process
needlessly for 2 more weeks, can we just finally be done with it?

We had long discussions for 2 RFC's pros and cons.
I'm sorry that I could not keep up the discussion. This may be proposed
already.

The root cause of why PHP should have stricter type/conversion check,
is users do have "wrong conversions". (I'm aware of other good reasons
but almost all of them are to have "correct code")

Anthony's proposal workarounds BC issue by having 2 modes (weak/strict)
by allowing "wrong conversions" in weak mode.

Zeev's proposal let users to have time for adopting new behavior and
coerce to fix wrong conversions.

However, "wrong conversion is wrong" by definition. "Wrong" cannot be
corrected unless code is fixed. Thus, users should fix them anyway.

Since both are trying to introduce strict typing to PHP for the sake of
code correctness, why don't we agree to have correct type conversion
by default?

We care for BC. Therefore, why don't we introduce change that can
spot where/what are wrong in users code at first, then change error
type in PHP8?

BC is not bad things to have always, but BC can do good. e.g. Enforce
users to correct "wrong conversion". In other words, enforce users to have
"correct codes".

Current Zeev's proposal may not give users enough time to adopt. If we
enforce "correct conversions" in PHP8, it would be long enough for adoption
period.

Since both of your objective is to have "correct conversions", let's have
"correct conversions" only, let's forget about weak type hints. Weak type
hint
does allow "wrong conversions" and we are better to avoid it. IMHO.

I think mix of your proposals would do the best.

Introduce E_DEPRECATED error for wrong conversions in PHP7
Change the E_DEPRECATED error to E_WARNING in PHP8
Have very strict type check that only checks zval data type. Perhaps
PHP8.

Regards,

P.S. Simple cast can create other type of bugs as I illustrated in other
thread unless we have casts that warn dangerous. Strict type check would
be good low level libraries, but it will hide problems in many average
users'
codes by errorless casts.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

A plea for unity on scalar types View as Markdown

Regards

Regards

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL