Hi all,
after all, some people are not happy with the current proposals about scalar types. So, they both still possibly may fail.
Thus, I'd like to come up with a fallback proposal in case both proposals fail:
https://wiki.php.net/rfc/basic_scalar_types
It shouldn't prevent any future improvements and still give use all the advantages of scalar types.
Thanks,
Bob
Hi all,
after all, some people are not happy with the current proposals about
scalar types. So, they both still possibly may fail.Thus, I'd like to come up with a fallback proposal in case both proposals
fail:https://wiki.php.net/rfc/basic_scalar_types
It shouldn't prevent any future improvements and still give use all the
advantages of scalar types.
I would definitely vote +1.
I think this would be the best decision for now.
Thanks. Dmitry.
Thanks,
Bob
Am 11.03.2015 um 22:28 schrieb Bob Weinand:
Hi all,
after all, some people are not happy with the current proposals about scalar types. So, they both still possibly may fail.
Thus, I'd like to come up with a fallback proposal in case both proposals fail:
https://wiki.php.net/rfc/basic_scalar_types
It shouldn't prevent any future improvements and still give use all the advantages of scalar types.
Thanks,
Bob
From me although a +1 vote.
--
DerOetzi
after all, some people are not happy with the current proposals about scalar types. So, they both still possibly may fail.
Thus, I'd like to come up with a fallback proposal in case both proposals fail:
https://wiki.php.net/rfc/basic_scalar_types
It shouldn't prevent any future improvements and still give use all the advantages of scalar types.
You have my axe, by which I mean +1.
Adam
Hi all,
after all, some people are not happy with the current proposals about
scalar types. So, they both still possibly may fail.Thus, I'd like to come up with a fallback proposal in case both proposals
fail:https://wiki.php.net/rfc/basic_scalar_types
It shouldn't prevent any future improvements and still give use all the
advantages of scalar types.
Besides what I think of proposing yet another RFC, -1 because it is
basically what the initial idea from the opponents of optional strict mode
wanted before they go with the latest one. It also totally ignore what the
Anthony's proposes.
Thanks,
Bob
It shouldn't prevent any future improvements and still give use all the
advantages of scalar types.Besides what I think of proposing yet another RFC, -1 because it is
basically what the initial idea from the opponents of optional strict mode
wanted before they go with the latest one. It also totally ignore what the
Anthony's proposes.
Hello,
I'd say that this is definitely better than the dual mode RFC, but
worse than the coercive one - I can't find a single reason why some
modes switch should be good. I can only see negative outcomes from
this, and a painful experience when developing with PHP in the long
run as a userland developer.
Basically goes with what I've been saying from the beggining of the
introduction of the "dual mode" - I don't care if strong or weak
typing wins, but I want only on in the language. PHP is inconsistent,
there's no need to make even more inconsistencies and stuff.
Regards
Pavel Kouril
Am 11.03.2015 um 23:29 schrieb Pavel Kouřil pajousek@gmail.com:
It shouldn't prevent any future improvements and still give use all the
advantages of scalar types.Besides what I think of proposing yet another RFC, -1 because it is
basically what the initial idea from the opponents of optional strict mode
wanted before they go with the latest one. It also totally ignore what the
Anthony's proposes.Hello,
I'd say that this is definitely better than the dual mode RFC, but
worse than the coercive one - I can't find a single reason why some
modes switch should be good. I can only see negative outcomes from
this, and a painful experience when developing with PHP in the long
run as a userland developer.Basically goes with what I've been saying from the beggining of the
introduction of the "dual mode" - I don't care if strong or weak
typing wins, but I want only on in the language. PHP is inconsistent,
there's no need to make even more inconsistencies and stuff.Regards
Pavel Kouril
It's not worse than the coercive one. It's just doing less. It doesn't change ZPP.
We always still can change ZPP later in future.
If you like the coercive one, you also should like this one.
Bob
Am 11.03.2015 um 23:29 schrieb Pavel Kouřil pajousek@gmail.com:
It shouldn't prevent any future improvements and still give use all the
advantages of scalar types.Besides what I think of proposing yet another RFC, -1 because it is
basically what the initial idea from the opponents of optional strict
mode
wanted before they go with the latest one. It also totally ignore what
the
Anthony's proposes.Hello,
I'd say that this is definitely better than the dual mode RFC, but
worse than the coercive one - I can't find a single reason why some
modes switch should be good. I can only see negative outcomes from
this, and a painful experience when developing with PHP in the long
run as a userland developer.Basically goes with what I've been saying from the beggining of the
introduction of the "dual mode" - I don't care if strong or weak
typing wins, but I want only on in the language. PHP is inconsistent,
there's no need to make even more inconsistencies and stuff.Regards
Pavel KourilIt's not worse than the coercive one. It's just doing less. It doesn't
change ZPP.
We always still can change ZPP later in future.If you like the coercive one, you also should like this one.
Bob
Yeah, I like this one - but I slightly prefer the coercive one. I feel like
this one is just too weak (yes, because it doesn't change the ZPP), but it
is still better than no hints at all - and infinitely better than
introducing two modes.
Hopefully you understand my POV now. :)
Regards
Pavel Kouřil
Am 11.03.2015 um 23:23 schrieb Pierre Joye pierre.php@gmail.com:
Hi all,
after all, some people are not happy with the current proposals about scalar types. So, they both still possibly may fail.
Thus, I'd like to come up with a fallback proposal in case both proposals fail:
https://wiki.php.net/rfc/basic_scalar_types https://wiki.php.net/rfc/basic_scalar_types
It shouldn't prevent any future improvements and still give use all the advantages of scalar types.
Besides what I think of proposing yet another RFC, -1 because it is basically what the initial idea from the opponents of optional strict mode wanted before they go with the latest one. It also totally ignore what the Anthony's proposes.
Correct. It's just for the case where the other two fail.
We still can add strict mode in a later version if people need it.
All the RFC does is the most basic scalar type hinting you can build everything on. (for example adding the declare(strict_types=1); would work without any BC break on top of it)
I see that it doesn't fit all the users, but there's still room for improvement in later versions.
Bob
-----Original Message-----
From: Bob Weinand [mailto:bobwei9@hotmail.com]
Sent: Thursday, March 12, 2015 12:46 AM
To: Pierre Joye
Cc: PHP internals
Subject: Re: [PHP-DEV] [RFC] Basic Scalar TypesCorrect. It's just for the case where the other two fail.
We still can add strict mode in a later version if people need it.
All the RFC does is the most basic scalar type hinting you can build
everything
on. (for example adding the declare(strict_types=1); would work without
any
BC break on top of it)
The issue is that it's only possible to open the voting on this one until
tomorrow.
As I said, I do think we need something for 7.0. I went as far as
saying that I'd change my vote on the quite-bad-IMHO dual mode RFC to yes
if it seems both present proposals aren't going to succeed. But I would
much rather see this one pass over the dual mode if it was available for a
vote.
So really, the options we have are:
- Put this one for a vote before the end of tomorrow. Here too, on a
personal level, if I see that this proposal isn't gaining enough votes,
I'd support the dual mode one. - Don't put it up for a vote, and then we may or may not have something
for 7.0.
Zeev
2015-03-12 11:23 GMT+02:00 Zeev Suraski zeev@zend.com:
-----Original Message-----
From: Bob Weinand [mailto:bobwei9@hotmail.com]
Sent: Thursday, March 12, 2015 12:46 AM
To: Pierre Joye
Cc: PHP internals
Subject: Re: [PHP-DEV] [RFC] Basic Scalar TypesCorrect. It's just for the case where the other two fail.
We still can add strict mode in a later version if people need it.
All the RFC does is the most basic scalar type hinting you can build
everything
on. (for example adding the declare(strict_types=1); would work without
any
BC break on top of it)The issue is that it's only possible to open the voting on this one until
tomorrow.As I said, I do think we need something for 7.0. I went as far as
saying that I'd change my vote on the quite-bad-IMHO dual mode RFC to yes
if it seems both present proposals aren't going to succeed. But I would
much rather see this one pass over the dual mode if it was available for a
vote.So really, the options we have are:
- Put this one for a vote before the end of tomorrow. Here too, on a
personal level, if I see that this proposal isn't gaining enough votes,
I'd support the dual mode one.- Don't put it up for a vote, and then we may or may not have something
for 7.0.Zeev
--
At this point I think the best way is to reserve the keywords for
typehints, and not the only 4, but also for resource and null. And work
towards making typehints in 7.1.
Rushing things like it's now never lead to any good results. And that
dual-mode RFC is re-incarnation of the register_globals, just in a
different way. But essentially will make the same mess.
Hi all,
after all, some people are not happy with the current proposals about
scalar types. So, they both still possibly may fail.Thus, I'd like to come up with a fallback proposal in case both proposals
fail:https://wiki.php.net/rfc/basic_scalar_types
It shouldn't prevent any future improvements and still give use all the
advantages of scalar types.
Before I even start thinking about this, I'd like to have clarification as
to whether this RFC is still eligible for targeting the PHP 7.0 release.
The currently accepted interpretation is that all RFC votes must have
started by March 15th, which is irreconcilable with an RFC that was only
submitted today.
Does this mean that we're delaying the PHP 7 schedule by two weeks?
I feel like this topic is getting out of control. It's been discussed for
months, now we had one vote on Andrea's withdrawn proposal, then another
vote on Anthony's proposal, then another vote on the Zeev et al proposal -
and then we're going to have another one on Bob's proposal? With every vote
taking another couple of weeks. Hey, maybe I should also submit a STH
proposal that we can vote on after that?
If both Anthony's and Zeev's proposal fail, I would recommend to just drop
this topic for 7.0 and discuss it again for PHP 7.1. The necessary
forward-compatibility changes to allow that are already proposed in another
RFC.
Nikita
Hi all,
after all, some people are not happy with the current proposals about
scalar types. So, they both still possibly may fail.Thus, I'd like to come up with a fallback proposal in case both proposals
fail:https://wiki.php.net/rfc/basic_scalar_types
It shouldn't prevent any future improvements and still give use all the
advantages of scalar types.Before I even start thinking about this, I'd like to have clarification as
to whether this RFC is still eligible for targeting the PHP 7.0 release.
The currently accepted interpretation is that all RFC votes must have
started by March 15th, which is irreconcilable with an RFC that was only
submitted today.Does this mean that we're delaying the PHP 7 schedule by two weeks?
I feel like this topic is getting out of control. It's been discussed for
months, now we had one vote on Andrea's withdrawn proposal, then another
vote on Anthony's proposal, then another vote on the Zeev et al proposal -
and then we're going to have another one on Bob's proposal? With every vote
taking another couple of weeks. Hey, maybe I should also submit a STH
proposal that we can vote on after that?If both Anthony's and Zeev's proposal fail, I would recommend to just drop
this topic for 7.0 and discuss it again for PHP 7.1. The necessary
forward-compatibility changes to allow that are already proposed in another
RFC.
Bob proposes the base common part of both other RFCs.
It actually had to be proposed in first place.
I would prefer this instead of nothing. I think many people think the same.
Thanks. Dmitry.
Nikita
Dmitry,
I tend to disagree with many people wanting this over nothing. It's a big
enough topic,
that raised waives in the community, to be treated properly and not just
throw it in before
feature freeze, so I agree with Nikita on this one.
My view on it is that if both RFC's fail, the feature should not be in 7.0
and have a proper
solution for 7.x, what ever that x might be, a solution that satisfies both
internals and userland.
On that topic, it's a shame that all this work and effort might be thrown
away and at the end of
the day we would be left with nothing.
Regards,
Stelian
On Thu, Mar 12, 2015 at 1:53 AM, Nikita Popov nikita.ppv@gmail.com
wrote:On Wed, Mar 11, 2015 at 10:28 PM, Bob Weinand bobwei9@hotmail.com
wrote:Hi all,
after all, some people are not happy with the current proposals about
scalar types. So, they both still possibly may fail.Thus, I'd like to come up with a fallback proposal in case both
proposals
fail:https://wiki.php.net/rfc/basic_scalar_types
It shouldn't prevent any future improvements and still give use all the
advantages of scalar types.Before I even start thinking about this, I'd like to have clarification
as
to whether this RFC is still eligible for targeting the PHP 7.0 release.
The currently accepted interpretation is that all RFC votes must have
started by March 15th, which is irreconcilable with an RFC that was only
submitted today.Does this mean that we're delaying the PHP 7 schedule by two weeks?
I feel like this topic is getting out of control. It's been discussed for
months, now we had one vote on Andrea's withdrawn proposal, then another
vote on Anthony's proposal, then another vote on the Zeev et al proposal
and then we're going to have another one on Bob's proposal? With every
vote
taking another couple of weeks. Hey, maybe I should also submit a STH
proposal that we can vote on after that?If both Anthony's and Zeev's proposal fail, I would recommend to just
drop
this topic for 7.0 and discuss it again for PHP 7.1. The necessary
forward-compatibility changes to allow that are already proposed in
another
RFC.Bob proposes the base common part of both other RFCs.
It actually had to be proposed in first place.
I would prefer this instead of nothing. I think many people think the same.Thanks. Dmitry.
Nikita
after all, some people are not happy with the current proposals about scalar types. So, they both still possibly may fail.
Thus, I'd like to come up with a fallback proposal in case both proposals fail:
https://wiki.php.net/rfc/basic_scalar_types
It shouldn't prevent any future improvements and still give use all the advantages of scalar types.
I'm not sure I'm seeing improvements over the other RFCs here ... or I
just missed something obvious. From a quick glance, this one here:
Type declration "string" and you pass in a "bool" type.
When in practive the conversion is like this:
$ php -r 'var_dump( (string) false ); var_dump( (string) true );'
string(0) ""
string(1) "1"
$ php -v
PHP 5.5.9-1ubuntu4.6 (cli) (built: Feb 13 2015 19:17:11)
- Markus
Hi all,
after all, some people are not happy with the current proposals about scalar types. So, they both still possibly may fail.
Thus, I'd like to come up with a fallback proposal in case both proposals fail:
https://wiki.php.net/rfc/basic_scalar_types
It shouldn't prevent any future improvements and still give use all the advantages of scalar types.
Agree and I would vote +1 on this even if I'd prefer coercive.
It is a very valid option for a 7.0 and it is future proof.
Thanks,
Bob
Hi all,
Hi all,
after all, some people are not happy with the current proposals about
scalar types. So, they both still possibly may fail.Thus, I'd like to come up with a fallback proposal in case both
proposals fail:https://wiki.php.net/rfc/basic_scalar_types
It shouldn't prevent any future improvements and still give use all the
advantages of scalar types.Agree and I would vote +1 on this even if I'd prefer coercive.
It is a very valid option for a 7.0 and it is future proof.
The same opinion.
I prefer coercive, but it's good enough for now.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Not that another +1 is needed, but I'm with Andi here. I do personally
like this 3rd proposal as an option, if nothing else because it
implements the 'simpler base' at the moment, and allows us, once people
are used to this being part of the language, to continue to evolve
later. And that evolution can be based upon our real world experience
of using this 'base level' of typehinting for a while.
Versus the more complicated versions, of which both Zeev's and Anthony's
are. In each their own way.
Eli
Agree and I would vote +1 on this even if I'd prefer coercive. It is a
very valid option for a 7.0 and it is future proof.
--
| Eli White | http://eliw.com/ | Twitter: EliW |
So to get it clear for everyone: the right way is for internals to ignore
community as a
whole, stick to their own views and implement something nobody actually
wants - just
because there is no time - on the idea that "something is better than
nothing"?
Without pointing any fingers it sure looks like a stalling tactic where
someone
eventually gets what they want.
Highly disappointed on this outcome.
Not that another +1 is needed, but I'm with Andi here. I do personally
like this 3rd proposal as an option, if nothing else because it
implements the 'simpler base' at the moment, and allows us, once people
are used to this being part of the language, to continue to evolve
later. And that evolution can be based upon our real world experience
of using this 'base level' of typehinting for a while.Versus the more complicated versions, of which both Zeev's and Anthony's
are. In each their own way.Eli
Agree and I would vote +1 on this even if I'd prefer coercive. It is a
very valid option for a 7.0 and it is future proof.--
| Eli White | http://eliw.com/ | Twitter: EliW |
+1 on this, as this is more inline with how ZPP currently works, creating
less headaches to end users.
So to get it clear for everyone: the right way is for internals to ignore
community as a
whole, stick to their own views and implement something nobody actually
wants - just
because there is no time - on the idea that "something is better than
nothing"?Without pointing any fingers it sure looks like a stalling tactic where
someone
eventually gets what they want.Highly disappointed on this outcome.
Not that another +1 is needed, but I'm with Andi here. I do personally
like this 3rd proposal as an option, if nothing else because it
implements the 'simpler base' at the moment, and allows us, once people
are used to this being part of the language, to continue to evolve
later. And that evolution can be based upon our real world experience
of using this 'base level' of typehinting for a while.Versus the more complicated versions, of which both Zeev's and Anthony's
are. In each their own way.Eli
Agree and I would vote +1 on this even if I'd prefer coercive. It is a
very valid option for a 7.0 and it is future proof.--
| Eli White | http://eliw.com/ | Twitter: EliW |
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
"guilhermeblanco@gmail.com" guilhermeblanco@gmail.com schreef op 13 maart 2015 18:57:35 GMT+00:00:
+1 on this, as this is more inline with how ZPP currently works,
creating
less headaches to end users.On Fri, Mar 13, 2015 at 2:33 PM, Stelian Mocanita stelianm@php.net
wrote:So to get it clear for everyone: the right way is for internals to
ignore
community as a
whole, stick to their own views and implement something nobody
actually
wants - just
because there is no time - on the idea that "something is better
than
nothing"?Without pointing any fingers it sure looks like a stalling tactic
where
someone
eventually gets what they want.Highly disappointed on this outcome.
Not that another +1 is needed, but I'm with Andi here. I do
personally
like this 3rd proposal as an option, if nothing else because it
implements the 'simpler base' at the moment, and allows us, once
people
are used to this being part of the language, to continue to evolve
later. And that evolution can be based upon our real world
experience
of using this 'base level' of typehinting for a while.Versus the more complicated versions, of which both Zeev's and
Anthony's
are. In each their own way.Eli
Agree and I would vote +1 on this even if I'd prefer coercive. It
is a
very valid option for a 7.0 and it is future proof.--
| Eli White | http://eliw.com/ | Twitter: EliW |
Chance of this RFC passing is going to be slim, as it only caters for one of the three groups that Antony described...
I certainly will vote against it.
-----Original Message-----
From: Derick Rethans [mailto:derick@php.net]
Sent: Friday, March 13, 2015 10:34 PM
To: guilhermeblanco@gmail.com; Stelian Mocanita
Cc: Eli; PHP Internals List
Subject: Re: [PHP-DEV] [RFC] Basic Scalar TypesChance of this RFC passing is going to be slim, as it only caters for one
of the
three groups that Antony described...I certainly will vote against it.
You may very well be right, but the only way of truly knowing would be
putting it up for a vote. I'd feel a lot more comfortable if this was also
available for a vote before moving my nay to yay on the Dual Mode RFC.
Zeev
-----Original Message-----
From: Derick Rethans [mailto:derick@php.net]
Sent: Friday, March 13, 2015 10:34 PM
To: guilhermeblanco@gmail.com; Stelian Mocanita
Cc: Eli; PHP Internals List
Subject: Re: [PHP-DEV] [RFC] Basic Scalar TypesChance of this RFC passing is going to be slim, as it only caters for one
of the
three groups that Antony described...I certainly will vote against it.
You may very well be right, but the only way of truly knowing would be
putting it up for a vote. I'd feel a lot more comfortable if this was also
available for a vote before moving my nay to yay on the Dual Mode RFC.
I don't get it.
you called Andrea out for not putting up v1 of her RFC for vote because it
had so much momentum behind it.
Instead of just doing what bwoebi did you put up another RFC that got much
more negative tone from the beginning.
We agree on having a vote on two RFCs, coercive and v5.
Now that coercive is the clear loser suddenly v1 must be up for vote as
well?
You had the chance to do just this.
Zeev
-----Original Message-----
From: Derick Rethans [mailto:derick@php.net]
Sent: Friday, March 13, 2015 10:34 PM
To: guilhermeblanco@gmail.com; Stelian Mocanita
Cc: Eli; PHP Internals List
Subject: Re: [PHP-DEV] [RFC] Basic Scalar TypesChance of this RFC passing is going to be slim, as it only caters for
one
of the
three groups that Antony described...I certainly will vote against it.
You may very well be right, but the only way of truly knowing would be
putting it up for a vote. I'd feel a lot more comfortable if this was
also
available for a vote before moving my nay to yay on the Dual Mode RFC.I don't get it.
you called Andrea out for not putting up v1 of her RFC for vote because it
had so much momentum behind it.
Instead of just doing what bwoebi did you put up another RFC that got
much
more negative tone from the beginning.
We agree on having a vote on two RFCs, coercive and v5.
Now that coercive is the clear loser suddenly v1 must be up for vote as
well?
I totally agree with your comment, it looks a bit like a desperate move or
attempt to block or counter the other one.
We should really stop that...
You had the chance to do just this.
Zeev
I really want to understand if we're gonna allow this RFC voting or not.
That's important to reconsider my vote on STH
-----Original Message-----
From: Derick Rethans [mailto:derick@php.net]
Sent: Friday, March 13, 2015 10:34 PM
To: guilhermeblanco@gmail.com; Stelian Mocanita
Cc: Eli; PHP Internals List
Subject: Re: [PHP-DEV] [RFC] Basic Scalar TypesChance of this RFC passing is going to be slim, as it only caters for
one
of the
three groups that Antony described...I certainly will vote against it.
You may very well be right, but the only way of truly knowing would be
putting it up for a vote. I'd feel a lot more comfortable if this was
also
available for a vote before moving my nay to yay on the Dual Mode RFC.I don't get it.
you called Andrea out for not putting up v1 of her RFC for vote because
it
had so much momentum behind it.
Instead of just doing what bwoebi did you put up another RFC that got
much
more negative tone from the beginning.
We agree on having a vote on two RFCs, coercive and v5.
Now that coercive is the clear loser suddenly v1 must be up for vote as
well?I totally agree with your comment, it looks a bit like a desperate move or
attempt to block or counter the other one.We should really stop that...
You had the chance to do just this.
Zeev
--
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
I really want to understand if we're gonna allow this RFC voting or not.
That's important to reconsider my vote on STH
Well, if we look at it the theoretical way, then no, we won't be able
to consider this one for PHP 7:
-
It got announced on the 11th [1]
-
A minimum of two weeks required for discussion [2]
-
RFCs can only be submitted for voting before Mar 15th [3]
cheers,
Derick
-----Original Message-----
From: Benjamin Eberlei [mailto:kontakt@beberlei.de]
Sent: Friday, March 13, 2015 10:50 PM
To: Zeev Suraski
Cc: Derick Rethans; Eli; Guilherme Blanco; Stelian Mocanita; PHP Internals
List
Subject: Re: [PHP-DEV] [RFC] Basic Scalar Types-----Original Message-----
From: Derick Rethans [mailto:derick@php.net]
Sent: Friday, March 13, 2015 10:34 PM
To: guilhermeblanco@gmail.com; Stelian Mocanita
Cc: Eli; PHP Internals List
Subject: Re: [PHP-DEV] [RFC] Basic Scalar TypesChance of this RFC passing is going to be slim, as it only caters for
one
of the
three groups that Antony described...I certainly will vote against it.
You may very well be right, but the only way of truly knowing would
be
putting it up for a vote. I'd feel a lot more comfortable if this was
also
available for a vote before moving my nay to yay on the Dual Mode
RFC.I don't get it.
you called Andrea out for not putting up v1 of her RFC for vote because it
had so much momentum behind it.
Instead of just doing what bwoebi did you put up another RFC that got
much more negative tone from the beginning.
We agree on having a vote on two RFCs, coercive and v5.
Now that coercive is the clear loser suddenly v1 must be up for vote as
well?You had the chance to do just this.
Benjamin,
Maybe I was naïve, but I thought I had a better way to make both weak &
strict camps happy, instead of just ignoring the strict camp altogether.
While there was some opposition to it - it mostly came from the main
proponents of the Strict camp, and, well, you :) Clearly right now it seems
that not a lot of people bought into the coercive approach, and while I hope
it can be turned around - I realize the chances for that happening aren't
stellar. Given we can go to a vote on Bob's RFC tomorrow without having to
delay the PHP 7 timeline, I don't see strong reasons not to do it, and put
to rest any theories about what might have happened if v0.1 ever went for a
vote.
Zeev
Maybe I was naïve, but I thought I had a better way to make both weak &
strict camps happy,
By dropping strict despite all discussions, proposing a pandara box rfc by
changing the casting rules and now suddenly proposing to go vote to yet
another "perfect" RFC? Sorry, it does not help anyone and damages php,
creates yet more issues. This is not a good call.
Zeev, allow me to understand how this goes. Bob's discussions on the RFC
started 2 days ago. Based on the current rules, the RFC can only go to vote
after 2 weeks. That means in 12 days starting now.
So we are either violating the RFC rules by pushing the vote tomorrow or
we're
delaying PHP7 for another 2 weeks maybe yet another TH RFC passes?
Pointing at number 6 from https://wiki.php.net/rfc/howto
Maybe I was naïve, but I thought I had a better way to make both weak &
strict camps happy,By dropping strict despite all discussions, proposing a pandara box rfc by
changing the casting rules and now suddenly proposing to go vote to yet
another "perfect" RFC? Sorry, it does not help anyone and damages php,
creates yet more issues. This is not a good call.
-----Original Message-----
From: stelian.mocanita@gmail.com [mailto:stelian.mocanita@gmail.com]
On Behalf Of Stelian Mocanita
Sent: Saturday, March 14, 2015 12:18 AM
To: Pierre Joye
Cc: Zeev Suraski; PHP internals; Benjamin Eberlei
Subject: Re: [PHP-DEV] [RFC] Basic Scalar TypesZeev, allow me to understand how this goes. Bob's discussions on the RFC
started 2 days ago. Based on the current rules, the RFC can only go to
vote
after 2 weeks. That means in 12 days starting now.So we are either violating the RFC rules by pushing the vote tomorrow or
we're delaying PHP7 for another 2 weeks maybe yet another TH RFC passes?
Bob's RFC is effectively Andrea's v0.1 RFC which was discussed in detail and
introduced well over two weeks ago.
I hope we're not going to go into more and more extremes of playing a law
firm and not an OS project.
Zeev
-----Original Message-----
From: stelian.mocanita@gmail.com [mailto:stelian.mocanita@gmail.com]
On Behalf Of Stelian Mocanita
Sent: Saturday, March 14, 2015 12:18 AM
To: Pierre Joye
Cc: Zeev Suraski; PHP internals; Benjamin Eberlei
Subject: Re: [PHP-DEV] [RFC] Basic Scalar TypesZeev, allow me to understand how this goes. Bob's discussions on the RFC
started 2 days ago. Based on the current rules, the RFC can only go to
vote
after 2 weeks. That means in 12 days starting now.So we are either violating the RFC rules by pushing the vote tomorrow or
we're delaying PHP7 for another 2 weeks maybe yet another TH RFC passes?Bob's RFC is effectively Andrea's v0.1 RFC which was discussed in detail
and
introduced well over two weeks ago.
No it is not. It is a new one, period. Just like this other rfc, discussed
months ago just went to vote without any discussions.
This is not the way it works and it has the bad taste of political moves.
I hope we're not going to go into more and more extremes of playing a law
firm and not an OS project.
So law is firm when it fits your goal but flexible when not? We have
relatively strict rules for this exact reason: nk double standard. Stop
playing with the rules and stand as someone willing to find compromises.
I'll switch my vote on STH v5 to YES.
If we get Basic STH into voting phase, I change my vote to NO and vote on
YES on Basic STH.
[]s,
-----Original Message-----
From: stelian.mocanita@gmail.com [mailto:stelian.mocanita@gmail.com]
On Behalf Of Stelian Mocanita
Sent: Saturday, March 14, 2015 12:18 AM
To: Pierre Joye
Cc: Zeev Suraski; PHP internals; Benjamin Eberlei
Subject: Re: [PHP-DEV] [RFC] Basic Scalar TypesZeev, allow me to understand how this goes. Bob's discussions on the
RFC
started 2 days ago. Based on the current rules, the RFC can only go to
vote
after 2 weeks. That means in 12 days starting now.So we are either violating the RFC rules by pushing the vote tomorrow
or
we're delaying PHP7 for another 2 weeks maybe yet another TH RFC
passes?Bob's RFC is effectively Andrea's v0.1 RFC which was discussed in detail
and
introduced well over two weeks ago.No it is not. It is a new one, period. Just like this other rfc, discussed
months ago just went to vote without any discussions.This is not the way it works and it has the bad taste of political moves.
I hope we're not going to go into more and more extremes of playing a law
firm and not an OS project.So law is firm when it fits your goal but flexible when not? We have
relatively strict rules for this exact reason: nk double standard. Stop
playing with the rules and stand as someone willing to find compromises.
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
On Mar 14, 2015 9:47 AM, "guilhermeblanco@gmail.com" <
guilhermeblanco@gmail.com> wrote:
I'll switch my vote on STH v5 to YES.
If we get Basic STH into voting phase, I change my vote to NO and vote on
YES on Basic STH.
I say it again: it should not be accepted. Or we can just scratch our rules
and I wi just ignore all time plan and do whatever I need to do to have
what I want in 7. Oh wait, that will be awkward. I won't do it.
Hi all,
On Mar 14, 2015 9:47 AM, "guilhermeblanco@gmail.com" <
guilhermeblanco@gmail.com> wrote:I'll switch my vote on STH v5 to YES.
If we get Basic STH into voting phase, I change my vote to NO and vote on
YES on Basic STH.I say it again: it should not be accepted. Or we can just scratch our rules
and I wi just ignore all time plan and do whatever I need to do to have
what I want in 7. Oh wait, that will be awkward. I won't do it.
Reading the actual rules, it seems pretty clear cut that moving this
to a vote would be a violation of those rules. I'm not a lawyer, or
even a frequent visitor to Internals, but this seems like the worst
possible time to debate those rules. As is usually the case, such
rules get their stress test at stressful times when the temptation to
suspend them is greatest, and this obviously qualifies as a stressful
time with a contest between ideologies that threaten to sink any
attempt to bring scalar type hinting to PHP.
The very notion that this might even be remotely possible is also
polluting opinion and the chances of either RFC currently in voting
passing. The timing, on the eve of when the first RFC into voting
would typically end, also looks fantastical. The hint that the rules
can be suspended, bent or otherwise driven around, frankly stinks and
looks like politics gone wild. And yes, appearances are actually quite
important.
Are there any other rules waiting to be unilaterally suspended? I
guess we'll see...
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zeev,
Zeev, allow me to understand how this goes. Bob's discussions on the RFC
started 2 days ago. Based on the current rules, the RFC can only go to
vote
after 2 weeks. That means in 12 days starting now.So we are either violating the RFC rules by pushing the vote tomorrow or
we're delaying PHP7 for another 2 weeks maybe yet another TH RFC passes?Bob's RFC is effectively Andrea's v0.1 RFC which was discussed in detail and
introduced well over two weeks ago.
I hope we're not going to go into more and more extremes of playing a law
firm and not an OS project.
We have minimum discussion periods for a reason. To allow people the
time to review proposals as much as to discuss them.
On the surface, yes, this looks like Andrea's 0.1 RFC. However, after
looking at it, it's definitely different. There's a very significant
behavior difference between the two:
Andrea's RFC had the following wording:
The only exception to this is the handling of NULL: in order to be consistent with our existing type hints for classes, callables and arrays,
NULLis not accepted by default, unless the parameter is explicitly given a default value of NULL. This would work well with the draft Declaring Nullable Types RFC.
This proposal has a different behavior here. It explicitly allows
nulls for types:
function foo(int $abc) { var_dump($abc); }
Unlike my proposal and any of Andrea's, calling foo(null) will be
int(0) instead of an error.
This is an important distinction as it basically undermines any
attempt at a nullable RFC, since it makes primitives implicitly
nullable.
So it's not effectively the original proposal. It does differ in a
very significant detail. This is why we have mandatory discussion
periods. Not for "playing law firm" but for being fair to each other.
Anthony.
Zeev,
Zeev, allow me to understand how this goes. Bob's discussions on the RFC
started 2 days ago. Based on the current rules, the RFC can only go to
vote
after 2 weeks. That means in 12 days starting now.So we are either violating the RFC rules by pushing the vote tomorrow or
we're delaying PHP7 for another 2 weeks maybe yet another TH RFC passes?Bob's RFC is effectively Andrea's v0.1 RFC which was discussed in detail and
introduced well over two weeks ago.
I hope we're not going to go into more and more extremes of playing a law
firm and not an OS project.We have minimum discussion periods for a reason. To allow people the
time to review proposals as much as to discuss them.On the surface, yes, this looks like Andrea's 0.1 RFC. However, after
looking at it, it's definitely different. There's a very significant
behavior difference between the two:Andrea's RFC had the following wording:
The only exception to this is the handling of NULL: in order to be consistent with our existing type hints for classes, callables and arrays,
NULLis not accepted by default, unless the parameter is explicitly given a default value of NULL. This would work well with the draft Declaring Nullable Types RFC.This proposal has a different behavior here. It explicitly allows
nulls for types:function foo(int $abc) { var_dump($abc); }
Unlike my proposal and any of Andrea's, calling foo(null) will be
int(0) instead of an error.This is an important distinction as it basically undermines any
attempt at a nullable RFC, since it makes primitives implicitly
nullable.So it's not effectively the original proposal. It does differ in a
very significant detail. This is why we have mandatory discussion
periods. Not for "playing law firm" but for being fair to each other.Anthony.
--
Hello,
good catch. Nullable RFC would IMHO help PHP, and underminding it isn't good.
Regards
Pavel Kouril
Am 15.03.2015 um 18:48 schrieb Anthony Ferrara ircmaxell@gmail.com:
Andrea's RFC had the following wording:
The only exception to this is the handling of NULL: in order to be consistent with our existing type hints for classes, callables and arrays,
NULLis not accepted by default, unless the parameter is explicitly given a default value of NULL. This would work well with the draft Declaring Nullable Types RFC.This proposal has a different behavior here. It explicitly allows
nulls for types:function foo(int $abc) { var_dump($abc); }
Unlike my proposal and any of Andrea's, calling foo(null) will be
int(0) instead of an error.This is an important distinction as it basically undermines any
attempt at a nullable RFC, since it makes primitives implicitly
nullable.Anthony.
Anthony,
I think you've got something wrong there. It won't undermine an attempt at a nullable RFC.
In the weak scalar typing world, nullables won't change what we accept, but what we receive.
function (int|null $abc) { var_dump($abc); }
(or ?int or whatever syntax we will use)
would allow null to not be casted here.
Means foo(null) will lead to $abc being null and not int(0) with that signature.
Bob
Am 15.03.2015 um 18:48 schrieb Anthony Ferrara ircmaxell@gmail.com:
Andrea's RFC had the following wording:
The only exception to this is the handling of NULL: in order to be consistent with our existing type hints for classes, callables and arrays,
NULLis not accepted by default, unless the parameter is explicitly given a default value of NULL. This would work well with the draft Declaring Nullable Types RFC.This proposal has a different behavior here. It explicitly allows
nulls for types:function foo(int $abc) { var_dump($abc); }
Unlike my proposal and any of Andrea's, calling foo(null) will be
int(0) instead of an error.This is an important distinction as it basically undermines any
attempt at a nullable RFC, since it makes primitives implicitly
nullable.Anthony.
Anthony,
I think you've got something wrong there. It won't undermine an attempt at a nullable RFC.
In the weak scalar typing world, nullables won't change what we accept, but what we receive.
function (int|null $abc) { var_dump($abc); }
(or ?int or whatever syntax we will use)would allow null to not be casted here.
Means foo(null) will lead to $abc being null and not int(0) with that signature.
I think allowing null for an int is an error. Converting a null to
zero on a type boundary is harmful in my opinion.
2015-03-15 19:13 GMT+01:00 Levi Morrison levim@php.net:
Am 15.03.2015 um 18:48 schrieb Anthony Ferrara ircmaxell@gmail.com:
Andrea's RFC had the following wording:
The only exception to this is the handling of NULL: in order to be consistent with our existing type hints for classes, callables and arrays,
NULLis not accepted by default, unless the parameter is explicitly given a default value of NULL. This would work well with the draft Declaring Nullable Types RFC.This proposal has a different behavior here. It explicitly allows
nulls for types:function foo(int $abc) { var_dump($abc); }
Unlike my proposal and any of Andrea's, calling foo(null) will be
int(0) instead of an error.This is an important distinction as it basically undermines any
attempt at a nullable RFC, since it makes primitives implicitly
nullable.Anthony.
Anthony,
I think you've got something wrong there. It won't undermine an attempt at a nullable RFC.
In the weak scalar typing world, nullables won't change what we accept, but what we receive.
function (int|null $abc) { var_dump($abc); }
(or ?int or whatever syntax we will use)would allow null to not be casted here.
Means foo(null) will lead to $abc being null and not int(0) with that signature.I think allowing
nullfor anintis an error. Converting a null to
zero on a type boundary is harmful in my opinion.
I agree, null shouldn't be allowed for int.
2015-03-15 19:13 GMT+01:00 Levi Morrison levim@php.net:
I think allowing
nullfor anintis an error. Converting a null to
zero on a type boundary is harmful in my opinion.I agree,
nullshouldn't be allowed forint.--
--
And this stuff is why we have minimum discussion periods, instead of
just trying to smash an RFC through because it resembles a version
that we liked a while ago.
The Basic STH RFC should go to vote - as Bob has said a few times - if
the Dual STH fails. Please do not try and take it over Zeev. It's
reckless, and feckless.
-----Original Message-----
From: Philip Sturgeon [mailto:pjsturgeon@gmail.com]
Sent: Sunday, March 15, 2015 10:07 PM
To: Niklas Keller
Cc: Levi Morrison; Bob Weinand; Anthony Ferrara; Zeev Suraski; Stelian
Mocanita; PHP internals
Subject: Re: [PHP-DEV] [RFC] Basic Scalar Types2015-03-15 19:13 GMT+01:00 Levi Morrison levim@php.net:
I think allowing
nullfor anintis an error. Converting a null
to zero on a type boundary is harmful in my opinion.I agree,
nullshouldn't be allowed forint.--
To unsubscribe,
visit: http://www.php.net/unsub.php--
To unsubscribe,
visit: http://www.php.net/unsub.phpAnd this stuff is why we have minimum discussion periods, instead of just
trying to smash an RFC through because it resembles a version that we
liked
a while ago.The Basic STH RFC should go to vote - as Bob has said a few times - if the
Dual STH fails. Please do not try and take it over Zeev. It's reckless,
and
feckless.
If I do, that has nothing to do with what you point out; I'll wait for a
discussion period exactly as Bob intends to. Although at this point I'm
strongly leaning towards not doing that and hoping Bob will change his mind
and give that proposal the fair chance it deserves.
Zeev
I think allowing
nullfor anintis an error. Converting a null tozero on a type boundary is harmful in my opinion.
I agree,nullshouldn't be allowed forint.
That a database result set will have perfectly valid 'null' returns for
fields is perfectly normal practice. Even if with a full record those
fields would have numeric counts of say invoices for a period. Treating
the field as a '0' may be valid in some cases, but equally handling a
null return is valid.
While off topic here, very closely related is returning a 'null' object
when there are no return values. Now converting that to an exception is
simply wrong from a normal data flow process. null has a specific
function and value.
--
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
And none answered me... is this RFC gonna be allowed to enter on voting
phase for 7.0 or not?
This drastically changes my voted on STH v5 which ends EOD today.
[]s,
Zeev, allow me to understand how this goes. Bob's discussions on the RFC
started 2 days ago. Based on the current rules, the RFC can only go to vote
after 2 weeks. That means in 12 days starting now.So we are either violating the RFC rules by pushing the vote tomorrow or
we're
delaying PHP7 for another 2 weeks maybe yet another TH RFC passes?Pointing at number 6 from https://wiki.php.net/rfc/howto
On Fri, Mar 13, 2015 at 11:07 PM, Pierre Joye pierre.php@gmail.com
wrote:Maybe I was naïve, but I thought I had a better way to make both weak &
strict camps happy,By dropping strict despite all discussions, proposing a pandara box rfc
by
changing the casting rules and now suddenly proposing to go vote to yet
another "perfect" RFC? Sorry, it does not help anyone and damages php,
creates yet more issues. This is not a good call.
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
So sticking to the rules is now "playing law firm". The RFC Andreea
proposed has
been modified several times before going to vote. And we're not voting on
her RFC,
we're voting on Bob's that was proposed 2 days ago.
I have a feeling that this will go to vote tomorrow though.
On Fri, Mar 13, 2015 at 11:26 PM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:
And none answered me... is this RFC gonna be allowed to enter on voting
phase for 7.0 or not?This drastically changes my voted on STH v5 which ends EOD today.
[]s,
On Fri, Mar 13, 2015 at 6:17 PM, Stelian Mocanita stelianm@php.net
wrote:Zeev, allow me to understand how this goes. Bob's discussions on the RFC
started 2 days ago. Based on the current rules, the RFC can only go to
vote
after 2 weeks. That means in 12 days starting now.So we are either violating the RFC rules by pushing the vote tomorrow or
we're
delaying PHP7 for another 2 weeks maybe yet another TH RFC passes?Pointing at number 6 from https://wiki.php.net/rfc/howto
On Fri, Mar 13, 2015 at 11:07 PM, Pierre Joye pierre.php@gmail.com
wrote:Maybe I was naïve, but I thought I had a better way to make both weak
&
strict camps happy,By dropping strict despite all discussions, proposing a pandara box rfc
by
changing the casting rules and now suddenly proposing to go vote to yet
another "perfect" RFC? Sorry, it does not help anyone and damages php,
creates yet more issues. This is not a good call.--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
-----Original Message-----
From: stelian.mocanita@gmail.com [mailto:stelian.mocanita@gmail.com]
On Behalf Of Stelian Mocanita
Sent: Saturday, March 14, 2015 12:30 AM
To: guilhermeblanco@gmail.com
Cc: Pierre Joye; Zeev Suraski; PHP internals; Benjamin Eberlei
Subject: Re: [PHP-DEV] [RFC] Basic Scalar TypesSo sticking to the rules is now "playing law firm".
If voting on a virtually identical RFC to a one that's already been
discussed in detail, just so that we can pretend that if we vote on it we
'HAVE' to delay the PHP 7 timeline, then yes, this is being like a law firm
in my opinion, which ultimately are also just 'sticking by the rules'.
Zeev
Guilherme,
The v0.5 RFC vote is NOT ending today, but rather on EOD of the 25th.
Anthony put in the text saying that the vote will end no sooner than when
the vote for the competing RFC will end, and that's March 25th.
I hope we do get a chance to vote on the Basic RFC.
Zeev
-----Original Message-----
From: guilhermeblanco@gmail.com [mailto:guilhermeblanco@gmail.com]
Sent: Saturday, March 14, 2015 12:26 AM
To: Stelian Mocanita
Cc: Pierre Joye; Zeev Suraski; PHP internals; Benjamin Eberlei
Subject: Re: [PHP-DEV] [RFC] Basic Scalar TypesAnd none answered me... is this RFC gonna be allowed to enter on voting
phase for 7.0 or not?This drastically changes my voted on STH v5 which ends EOD today.
[]s,
On Fri, Mar 13, 2015 at 6:17 PM, Stelian Mocanita stelianm@php.net
wrote:Zeev, allow me to understand how this goes. Bob's discussions on
the RFC
started 2 days ago. Based on the current rules, the RFC can only go
to vote
after 2 weeks. That means in 12 days starting now.So we are either violating the RFC rules by pushing the vote
tomorrow or
we're
delaying PHP7 for another 2 weeks maybe yet another TH RFC
passes?Pointing at number 6 from https://wiki.php.net/rfc/howto
On Fri, Mar 13, 2015 at 11:07 PM, Pierre Joye
pierre.php@gmail.com wrote:On Mar 14, 2015 9:03 AM, "Zeev Suraski" zeev@zend.com
wrote:Maybe I was naïve, but I thought I had a better way to make both
weak &
strict camps happy,By dropping strict despite all discussions, proposing a pandara box
rfc by
changing the casting rules and now suddenly proposing to go vote
to yet
another "perfect" RFC? Sorry, it does not help anyone and damages
php,
creates yet more issues. This is not a good call.--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
And none answered me... is this RFC gonna be allowed to enter on voting
phase for 7.0 or not?This drastically changes my voted on STH v5 which ends EOD today.
Actually it doesn't Guilherme. If you look at the STH v5 it states: "
will close the later of March 13, 2015 or the date that voting closes on
a competing RFC."
Zeev's competing RFC closes on March 25th. So Anthony's proposal also
ends on March 25th. There's still 12 days left for voting.
Eli
--
| Eli White | http://eliw.com/ | Twitter: EliW |
And none answered me... is this RFC gonna be allowed to enter on voting
phase for 7.0 or not?This drastically changes my voted on STH v5 which ends EOD today.
Actually it doesn't Guilherme. If you look at the STH v5 it states: "
will close the later of March 13, 2015 or the date that voting closes on
a competing RFC."Zeev's competing RFC closes on March 25th. So Anthony's proposal also
ends on March 25th. There's still 12 days left for voting.
And if voting is opened on THIS proposal, is it a competing proposal? So
closure on the other gets pushed back further?
From a practical point of view ...
Some sort of Type Hinting is coming in, so for those of us who can't be
bothered to have to deal with it, we just ignore it and ensure that any
third party library is maintained without it having the complications
created. If people want to fork those libraries then fair enough, but we
will simply have to ensure that every project is clear on just what
rules it is working to and manage a complete split in the code base ...
end of story.
--
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
Am 13.03.2015 um 23:03 schrieb Zeev Suraski zeev@zend.com:
Maybe I was naïve, but I thought I had a better way to make both weak &
strict camps happy, instead of just ignoring the strict camp altogether.
While there was some opposition to it - it mostly came from the main
proponents of the Strict camp, and, well, you :) Clearly right now it seems
that not a lot of people bought into the coercive approach, and while I hope
it can be turned around - I realize the chances for that happening aren't
stellar. Given we can go to a vote on Bob's RFC tomorrow without having to
delay the PHP 7 timeline, I don't see strong reasons not to do it, and put
to rest any theories about what might have happened if v0.1 ever went for a
vote.Zeev
I won't go into vote tomorrow.
Given that we already discussed that proposal a lot a few months ago (Andreas v1), we can go for a discussion phase a bit shorter (like 10 days total), but I won't put a new RFC into vote tomorrow. Especially as it's still being heavily discussed.
Also, this vote is just valid in case where other votes fail - so we actually don't compete with Anthonys RFC. It doesn't affect the voting period of Anthonys RFC. We can have the vote still going on a few days after both RFCs failed.
This RFC is only about the common part of both RFCs.
Bob
@Guilherme: I intend to put it into vote, yes.
-----Original Message-----
From: Bob Weinand [mailto:bobwei9@hotmail.com]
Sent: Saturday, March 14, 2015 1:07 AM
To: PHP Internals List
Cc: Zeev Suraski; guilhermeblanco@gmail.com
Subject: Re: [PHP-DEV] [RFC] Basic Scalar TypesAm 13.03.2015 um 23:03 schrieb Zeev Suraski zeev@zend.com:
Maybe I was naïve, but I thought I had a better way to make both
weak &
strict camps happy, instead of just ignoring the strict camp
altogether.
While there was some opposition to it - it mostly came from the
main
proponents of the Strict camp, and, well, you :) Clearly right now it
seems
that not a lot of people bought into the coercive approach, and while
I hope
it can be turned around - I realize the chances for that happening
aren't
stellar. Given we can go to a vote on Bob's RFC tomorrow without
having to
delay the PHP 7 timeline, I don't see strong reasons not to do it, and
put
to rest any theories about what might have happened if v0.1 ever
went for a
vote.Zeev
I won't go into vote tomorrow.
Given that we already discussed that proposal a lot a few months ago
(Andreas v1), we can go for a discussion phase a bit shorter (like 10 days
total), but I won't put a new RFC into vote tomorrow. Especially as it's
still
being heavily discussed.Also, this vote is just valid in case where other votes fail - so we
actually
don't compete with Anthonys RFC. It doesn't affect the voting period of
Anthonys RFC. We can have the vote still going on a few days after both
RFCs failed.
This RFC is only about the common part of both RFCs.
Bob,
If you don't put it into a vote by Sunday, then by definition it can't get
into v7.0 - unless we either have another vote to delay the timeline (big
hassle). Plus, as you can see, there are people (heck, even me) that would
vote in favor of the Dual Mode RFC just because there's no alternative.
Zeev
-----Original Message-----
From: Bob Weinand [mailto:bobwei9@hotmail.com]
Sent: Saturday, March 14, 2015 1:07 AM
To: PHP Internals List
Cc: Zeev Suraski; guilhermeblanco@gmail.com
Subject: Re: [PHP-DEV] [RFC] Basic Scalar TypesAm 13.03.2015 um 23:03 schrieb Zeev Suraski <zeev@zend.com>: Maybe I was naïve, but I thought I had a better way to make bothweak &
strict camps happy, instead of just ignoring the strict camp
altogether.
While there was some opposition to it - it mostly came from the
main
proponents of the Strict camp, and, well, you :) Clearly right
now it
seems
that not a lot of people bought into the coercive approach, and
while
I hope
it can be turned around - I realize the chances for that happening
aren't
stellar. Given we can go to a vote on Bob's RFC tomorrow without
having to
delay the PHP 7 timeline, I don't see strong reasons not to do
it, and
put
to rest any theories about what might have happened if v0.1 ever
went for a
vote.ZeevI won't go into vote tomorrow.
Given that we already discussed that proposal a lot a few months ago
(Andreas v1), we can go for a discussion phase a bit shorter (like 10
days
total), but I won't put a new RFC into vote tomorrow. Especially as it's
still
being heavily discussed.Also, this vote is just valid in case where other votes fail - so we
actually
don't compete with Anthonys RFC. It doesn't affect the voting period
of
Anthonys RFC. We can have the vote still going on a few days after both
RFCs failed.
This RFC is only about the common part of both RFCs.Bob,
If you don't put it into a vote by Sunday, then by definition it can't get
into v7.0 - unless we either have another vote to delay the timeline (big
hassle). Plus, as you can see, there are people (heck, even me) that
would
vote in favor of the Dual Mode RFC just because there's no alternative.
Then do it. And let move forward. :-)
This topic is killing us.
Zeev
Am 14.03.2015 um 00:14 schrieb Zeev Suraski zeev@zend.com:
-----Original Message-----
From: Bob Weinand [mailto:bobwei9@hotmail.com]
Sent: Saturday, March 14, 2015 1:07 AM
To: PHP Internals List
Cc: Zeev Suraski; guilhermeblanco@gmail.com
Subject: Re: [PHP-DEV] [RFC] Basic Scalar TypesI won't go into vote tomorrow.
Given that we already discussed that proposal a lot a few months ago
(Andreas v1), we can go for a discussion phase a bit shorter (like 10 days
total), but I won't put a new RFC into vote tomorrow. Especially as it's
still
being heavily discussed.Also, this vote is just valid in case where other votes fail - so we
actually
don't compete with Anthonys RFC. It doesn't affect the voting period of
Anthonys RFC. We can have the vote still going on a few days after both
RFCs failed.
This RFC is only about the common part of both RFCs.Bob,
If you don't put it into a vote by Sunday, then by definition it can't get
into v7.0 - unless we either have another vote to delay the timeline (big
hassle). Plus, as you can see, there are people (heck, even me) that would
vote in favor of the Dual Mode RFC just because there's no alternative.Zeev
Zeev,
If I put it into vote until Sunday, we're breaking the voting process. Which required an apt discussion phase which definitely isn't given when we start Sunday.
Also. Your timeline RFC leaves a bit room for interpretation ("Line up" means? Put into discussion? Vote? Have votes all already accepted?) . If necessary, I'll rather push timeline a bit than breaking vote process.
Thanks,
Bob
Zeev,
If I put it into vote until Sunday, we're breaking the voting process.
Which
required an apt discussion phase which definitely isn't given when we
start
Sunday.
Bob,
I do see it differently but obviously very much respect your position.
Why do I see it differently? The mandatory two week discussion period is
there to avoid a situation where there's not enough time to debate the
merit of the proposal, as well as to avoid 'stealth' RFCs where it's over
before some people even notice. Both of these elements aren't here. An
identical proposal has been debated in depth and from all possible
directions? Check. It's perhaps the most watched internals@ topic of all
times with zero chance for stealth RFCs? Check. There's not going to be
any new meaningful discussion over the next 10 days where something that
hasn't already been said will be said.
But again, I respect your position.
Also. Your timeline RFC leaves a bit room for interpretation ("Line up"
means? Put into discussion? Vote? Have votes all already accepted?) . If
necessary, I'll rather push timeline a bit than breaking vote process.
Good point. Looks like I shouldn't be writing non-technical RFCs as
they're always more than a bit open for interpretation :) Or at least
internals@ needs to scrutinize them more. Either way, you're right that
technically we could say your RFC is very much 'lined up' right now,
before the Mar 15 deadline.
While I'd hate to prolong the timeline for a technicality like that, for
this specific case I think it's worth it - it's an extremely important
topic and we've been dealing with it for almost a decade. Also, the good
news is that it's unlikely to delay the 2nd milestone given that we have
implementations for all of the different options already.
Now, my key concern is that you're saying you'd put it to a vote only if
you see both other RFCs are failing. The Dual Mode RFC is hovering above
and below passing, and we have no way of knowing how many people who voted
in favor of the Dual Mode RFC would actually much rather vote for the
Basic one if it was available (we know of at least one, and actually two
if you count me - my guess is there are a lot more). What I think makes
sense is to do something similar to what I did & plan to do with the
Coercive STH RFC - put it up to a vote as soon as practical; If we see
that it's not passing, withdraw it. I'm very clearly on the record saying
that if the Dual Mode RFC remains the only viable alternative (besides not
having anything) - I'll not only change my vote to yes, but also encourage
everyone else that I can to do the same (which I do think could swing at
least some votes). If Anthony's right and there's no chance it'll pass -
no harm done, except for maybe we've lost a couple of weeks.
Thoughts?
Zeev
Am 14.03.2015 um 00:44 schrieb Zeev Suraski zeev@zend.com:
Zeev,
If I put it into vote until Sunday, we're breaking the voting process.
Which
required an apt discussion phase which definitely isn't given when we
start
Sunday.Bob,
I do see it differently but obviously very much respect your position.
Why do I see it differently? The mandatory two week discussion period is
there to avoid a situation where there's not enough time to debate the
merit of the proposal, as well as to avoid 'stealth' RFCs where it's over
before some people even notice. Both of these elements aren't here. An
identical proposal has been debated in depth and from all possible
directions? Check. It's perhaps the most watched internals@ topic of all
times with zero chance for stealth RFCs? Check. There's not going to be
any new meaningful discussion over the next 10 days where something that
hasn't already been said will be said.But again, I respect your position.
Maybe that was the intention. But if you want that, we'd first need to allow that explicitly in the RFC.
If we just all act like "that rule doesn't fit my current situation, let's ignore it" … why do we then have rules at all?
I'd like to consider them as hard rules which we don't break, except a RM requires it.
Also. Your timeline RFC leaves a bit room for interpretation ("Line up"
means? Put into discussion? Vote? Have votes all already accepted?) . If
necessary, I'll rather push timeline a bit than breaking vote process.Good point. Looks like I shouldn't be writing non-technical RFCs as
they're always more than a bit open for interpretation :) Or at least
internals@ needs to scrutinize them more. Either way, you're right that
technically we could say your RFC is very much 'lined up' right now,
before the Mar 15 deadline.While I'd hate to prolong the timeline for a technicality like that, for
this specific case I think it's worth it - it's an extremely important
topic and we've been dealing with it for almost a decade. Also, the good
news is that it's unlikely to delay the 2nd milestone given that we have
implementations for all of the different options already.Now, my key concern is that you're saying you'd put it to a vote only if
you see both other RFCs are failing. The Dual Mode RFC is hovering above
and below passing, and we have no way of knowing how many people who voted
in favor of the Dual Mode RFC would actually much rather vote for the
Basic one if it was available (we know of at least one, and actually two
if you count me - my guess is there are a lot more). What I think makes
sense is to do something similar to what I did & plan to do with the
Coercive STH RFC - put it up to a vote as soon as practical; If we see
that it's not passing, withdraw it. I'm very clearly on the record saying
that if the Dual Mode RFC remains the only viable alternative (besides not
having anything) - I'll not only change my vote to yes, but also encourage
everyone else that I can to do the same (which I do think could swing at
least some votes). If Anthony's right and there's no chance it'll pass -
no harm done, except for maybe we've lost a couple of weeks.Thoughts?
Zeev
After having thought a lot about it, I'll announce my intentions shortly in a separate thread and clarify the way this RFC will go.
Bob
Am 14.03.2015 um 00:14 schrieb Zeev Suraski zeev@zend.com:
-----Original Message-----
From: Bob Weinand [mailto:bobwei9@hotmail.com]
Sent: Saturday, March 14, 2015 1:07 AM
To: PHP Internals List
Cc: Zeev Suraski; guilhermeblanco@gmail.com
Subject: Re: [PHP-DEV] [RFC] Basic Scalar TypesI won't go into vote tomorrow.
Given that we already discussed that proposal a lot a few months ago
(Andreas v1), we can go for a discussion phase a bit shorter (like 10 days
total), but I won't put a new RFC into vote tomorrow. Especially as it's
still
being heavily discussed.Also, this vote is just valid in case where other votes fail - so we
actually
don't compete with Anthonys RFC. It doesn't affect the voting period of
Anthonys RFC. We can have the vote still going on a few days after both
RFCs failed.
This RFC is only about the common part of both RFCs.Bob,
If you don't put it into a vote by Sunday, then by definition it can't get
into v7.0 - unless we either have another vote to delay the timeline (big
hassle). Plus, as you can see, there are people (heck, even me) that would
vote in favor of the Dual Mode RFC just because there's no alternative.Zeev
Zeev,
If I put it into vote until Sunday, we're breaking the voting process. Which required an apt discussion phase which definitely isn't given when we start Sunday.
Also. Your timeline RFC leaves a bit room for interpretation ("Line up" means? Put into discussion? Vote? Have votes all already accepted?) . If necessary, I'll rather push timeline a bit than breaking vote process.
Thanks,
Bob
If people (including Zeev) would not vote for Anthony's RFC knowing that
Bob's RFC will be put to a vote later, but would vote for Anthony's RFC
without Bob's RFC coming next, it sounds like Bob's RFC competes with
Anthony's RFC.
This whole thing is depressing. I am confident Zeev means well, but as
a usually silent watcher of this list, I'll give this bystander's view
of the recent discussion:
"I don't like X, but I'll vote for it unless I can get Y approved."
"I can't get Y approved, but I don't want to vote for X; How about Z?"
I know some people consider Z to be common ground because it is a sort
of intersection of X and Y, but it is clear that is not a consensus.
It's a little odd for me to write this email because I am someone who
personally isn't interested in strict typing at all, but the political
games make me sad, so I felt I needed to comment.
I try not to write often, so I'll throw in an off topic comment here:
Thanks, Stas! I've seen you write many common sense emails responding
to proposals that would make life harder for long time users without
bringing significant benefits. (Thanks to Lester for doing so also, but
somehow I expect it from Lester and appreciate it more from Stas.
Thanks to you both.)
- Todd
This whole thing is depressing. I am confident Zeev means well, but as a
usually silent watcher of this list, I'll give this bystander's view of
the recent
discussion:
"I don't like X, but I'll vote for it unless I can get Y approved."
"I can't get Y approved, but I don't want to vote for X; How about Z?"
I know some people consider Z to be common ground because it is a sort of
intersection of X and Y, but it is clear that is not a consensus.
I want to correct one statement in your description. I absolutely HATE 'X',
it's not that I don't like it. I think it's really bad. The only reason I
will vote for it and encourage others to do the same is for unity. And yes,
that's why I would absolutely want to explore any viable alternatives
beforehand (these two viable alternatives being Y and Z, there's no 4th
one).
I also think that while it's clear that there's no consensus behind Z - we
have no idea how much support it garners. If it has significantly more than
that for X, is it fair we're not giving it a chance? Should we not expect
the X supporters to vote in favor for Z for the sake of the very same unity?
Zeev
Hi,
2015-03-13 17:44 GMT-03:00 Zeev Suraski zeev@zend.com:
-----Original Message-----
From: Derick Rethans [mailto:derick@php.net]
Sent: Friday, March 13, 2015 10:34 PM
To: guilhermeblanco@gmail.com; Stelian Mocanita
Cc: Eli; PHP Internals List
Subject: Re: [PHP-DEV] [RFC] Basic Scalar TypesChance of this RFC passing is going to be slim, as it only caters for one
of the
three groups that Antony described...I certainly will vote against it.
You may very well be right, but the only way of truly knowing would be
putting it up for a vote. I'd feel a lot more comfortable if this was also
available for a vote before moving my nay to yay on the Dual Mode RFC.Zeev
--
So, are we extending the PH7 feature freeze now?
We all agreed that this couldn't be voted because all RFC votes must start
before March 15th, which is not reconcilable with the minimum 2 weeks
discussion period.
The suggestion to start yet another vote is a very disappointing attitude.
I started to contribute 2 months ago and now how can I don't loose the
trust on the RFC process if things are managed like that? This only causes
people to get demotivated to contribute to PHP and only puts the community
away.
-----Original Message-----
From: Derick Rethans [mailto:derick@php.net]
Sent: Friday, March 13, 2015 10:34 PM
To: guilhermeblanco@gmail.com; Stelian Mocanita
Cc: Eli; PHP Internals List
Subject: Re: [PHP-DEV] [RFC] Basic Scalar TypesChance of this RFC passing is going to be slim, as it only caters for one
of the
three groups that Antony described...I certainly will vote against it.
You may very well be right, but the only way of truly knowing would be
putting it up for a vote. I'd feel a lot more comfortable if this was also
available for a vote before moving my nay to yay on the Dual Mode RFC.Zeev
--
Votes for you. Votes for you. Votes for everyone!
Get Oprah in here.
But seriously Zeev, I read this as "lets do literally anything we can,
regardless of rules and process to avoid having the RFC that is
currently winning actually pass.
I don't want to assume this is a sneaky, underhand tactic, but it sure
does look quite like it.
-----Original Message-----
From: Philip Sturgeon [mailto:pjsturgeon@gmail.com]
Sent: Friday, March 13, 2015 11:16 PM
To: Zeev Suraski
Cc: Derick Rethans; Eli; guilhermeblanco@gmail.com; Stelian Mocanita; PHP
Internals List
Subject: Re: [PHP-DEV] [RFC] Basic Scalar TypesBut seriously Zeev, I read this as "lets do literally anything we can,
regardless
of rules and process to avoid having the RFC that is currently winning
actually
pass.I don't want to assume this is a sneaky, underhand tactic, but it sure
does
look quite like it.
Philip, Marcio,
You both raised the same issue so here's a combined answer. We can go to a
vote on Bob's RFC tomorrow, as it's practically identical to Andrea's v0.1
RFC. No need to prolong any timelines.
Philip, given I said that if I see no alternative RFC passing I'll change my
vote on the Dual Mode from no to yes, I'd appreciate if you stopped (very
strongly) implying there's anything sneaky or underhand about it. I will do
my best to get the Dual Mode RFC to pass, but not before I do my best to get
alternatives to it pass - because I think it's bad for PHP. Let's stop the
personal attacks, please.
Zeev
So to get it clear for everyone: the right way is for internals to ignore
community as a
whole, stick to their own views and implement something nobody actually
wants
Few people already told - they like this.
Thanks. Dmitry.
- just
because there is no time - on the idea that "something is better than
nothing"?Without pointing any fingers it sure looks like a stalling tactic where
someone
eventually gets what they want.Highly disappointed on this outcome.
Not that another +1 is needed, but I'm with Andi here. I do personally
like this 3rd proposal as an option, if nothing else because it
implements the 'simpler base' at the moment, and allows us, once people
are used to this being part of the language, to continue to evolve
later. And that evolution can be based upon our real world experience
of using this 'base level' of typehinting for a while.Versus the more complicated versions, of which both Zeev's and Anthony's
are. In each their own way.Eli
Agree and I would vote +1 on this even if I'd prefer coercive. It is a
very valid option for a 7.0 and it is future proof.--
| Eli White | http://eliw.com/ | Twitter: EliW |