RFC Link: https://wiki.php.net/rfc/reserve_more_types_in_php_7
The proposal has changed from the original. It no longer reserves the
aliases out of the interest of reserving the smallest useful,
uncontroversial subset. Some people want to remove aliases for these
types so in the interest of being as uncontroversial as possible I am
no longer proposing to remove them.
This will go into voting on March 15th unless something comes up
between now and then to persuade me otherwise.
RFC Link: https://wiki.php.net/rfc/reserve_more_types_in_php_7
The proposal has changed from the original. It no longer reserves the
aliases out of the interest of reserving the smallest useful,
uncontroversial subset. Some people want to remove aliases for these
types so in the interest of being as uncontroversial as possible I am
no longer proposing to remove them.This will go into voting on March 15th unless something comes up
between now and then to persuade me otherwise.--
Hello,
why do you consider a "true" and "false" as a type? It's not a type. it's a
value?
Regards
Pavel Kouril
Am 14.03.2015 um 10:21 schrieb Pavel Kouřil pajousek@gmail.com:
RFC Link: https://wiki.php.net/rfc/reserve_more_types_in_php_7
The proposal has changed from the original. It no longer reserves the
aliases out of the interest of reserving the smallest useful,
uncontroversial subset. Some people want to remove aliases for these
types so in the interest of being as uncontroversial as possible I am
no longer proposing to remove them.This will go into voting on March 15th unless something comes up
between now and then to persuade me otherwise.--
Hello,
why do you consider a "true" and "false" as a type? It's not a type. it's a
value?Regards
Pavel Kouril
These aren't types. But useful for e.g. union types (int|false). [By the way they're internally handled as different types… but that's an implementation detail…]
Also, he doesn't call them anywhere types, it's just the title.
Bob
Am 14.03.2015 um 10:21 schrieb Pavel Kouřil pajousek@gmail.com:
RFC Link: https://wiki.php.net/rfc/reserve_more_types_in_php_7
The proposal has changed from the original. It no longer reserves the
aliases out of the interest of reserving the smallest useful,
uncontroversial subset. Some people want to remove aliases for these
types so in the interest of being as uncontroversial as possible I am
no longer proposing to remove them.This will go into voting on March 15th unless something comes up
between now and then to persuade me otherwise.--
Hello,
why do you consider a "true" and "false" as a type? It's not a type. it's a
value?Regards
Pavel KourilThese aren't types. But useful for e.g. union types (int|false). [By the way they're internally handled as different types… but that's an implementation detail…]
Also, he doesn't call them anywhere types, it's just the title.
Bob
This is a solid plan. Vote this and everyone should +1 it, so if this
scalar squabble results in a a 0-0-0 score we can at least add scalars
later.
Regardless of scalar types it's just a good idea, and would give
lolphp one less thing to pissmoan about.
Am 14.03.2015 um 10:21 schrieb Pavel Kouřil pajousek@gmail.com:
RFC Link: https://wiki.php.net/rfc/reserve_more_types_in_php_7
The proposal has changed from the original. It no longer reserves the
aliases out of the interest of reserving the smallest useful,
uncontroversial subset. Some people want to remove aliases for these
types so in the interest of being as uncontroversial as possible I am
no longer proposing to remove them.This will go into voting on March 15th unless something comes up
between now and then to persuade me otherwise.--
Hello,
why do you consider a "true" and "false" as a type? It's not a type. it's a
value?Regards
Pavel KourilThese aren't types. But useful for e.g. union types (int|false). [By the way they're internally handled as different types… but that's an implementation detail…]
Also, he doesn't call them anywhere types, it's just the title.
Bob
This is a solid plan. Vote this and everyone should +1 it, so if this
scalar squabble results in a a 0-0-0 score we can at least add scalars
later.
This is not quite that obvious I don't think. If
https://wiki.php.net/rfc/context_sensitive_lexer isn't ready in time for
7.0 and we don't need to reserve these for one of the STH RFCs then we
should hold off and do it alongside the context sensitive lexer change
or we are going to needlessly break a ton of code including Drupal8:
https://github.com/drupal/drupal/blob/8.0.x/core/lib/Drupal/Component/Utility/String.php#L15
-Rasmus
2015-03-14 23:30 GMT+01:00 Rasmus Lerdorf rasmus@lerdorf.com:
On Sat, Mar 14, 2015 at 7:38 AM, Bob Weinand bobwei9@hotmail.com
wrote:Am 14.03.2015 um 10:21 schrieb Pavel Kouřil pajousek@gmail.com:
RFC Link: https://wiki.php.net/rfc/reserve_more_types_in_php_7
The proposal has changed from the original. It no longer reserves the
aliases out of the interest of reserving the smallest useful,
uncontroversial subset. Some people want to remove aliases for these
types so in the interest of being as uncontroversial as possible I am
no longer proposing to remove them.This will go into voting on March 15th unless something comes up
between now and then to persuade me otherwise.--
Hello,
why do you consider a "true" and "false" as a type? It's not a type.
it's a
value?Regards
Pavel KourilThese aren't types. But useful for e.g. union types (int|false). [By
the way they're internally handled as different types… but that's an
implementation detail…]Also, he doesn't call them anywhere types, it's just the title.
Bob
This is a solid plan. Vote this and everyone should +1 it, so if this
scalar squabble results in a a 0-0-0 score we can at least add scalars
later.This is not quite that obvious I don't think. If
https://wiki.php.net/rfc/context_sensitive_lexer isn't ready in time for
7.0 and we don't need to reserve these for one of the STH RFCs then we
should hold off and do it alongside the context sensitive lexer change
or we are going to needlessly break a ton of code including Drupal8:https://github.com/drupal/drupal/blob/8.0.x/core/lib/Drupal/Component/Utility/String.php#L15
-Rasmus
Rasmus, the context sensitive lexer doesn't change anything for Drupal.
Support for class names has been dropped, see
https://wiki.php.net/rfc/context_sensitive_lexer#rejected_features
Regards, Niklas
Rasmus, the context sensitive lexer doesn't change anything for Drupal.
Support for class names has been dropped,
see https://wiki.php.net/rfc/context_sensitive_lexer#rejected_features
Yes, I realize that. I just mentioned Drupal as an example of a major
codebase that will break as soon as we reserve "string". The context
sensitive lexer change will help minimize other types of breakages from
adding these reserved words, so I still think introducing them at them
same time makes sense.
-Rasmus
Am 14.03.2015 um 10:21 schrieb Pavel Kouřil pajousek@gmail.com:
RFC Link: https://wiki.php.net/rfc/reserve_more_types_in_php_7
The proposal has changed from the original. It no longer reserves the
aliases out of the interest of reserving the smallest useful,
uncontroversial subset. Some people want to remove aliases for these
types so in the interest of being as uncontroversial as possible I am
no longer proposing to remove them.This will go into voting on March 15th unless something comes up
between now and then to persuade me otherwise.--
Hello,
why do you consider a "true" and "false" as a type? It's not a type. it's a
value?Regards
Pavel KourilThese aren't types. But useful for e.g. union types (int|false). [By the way they're internally handled as different types… but that's an implementation detail…]
Also, he doesn't call them anywhere types, it's just the title.
Bob
This is a solid plan. Vote this and everyone should +1 it, so if this
scalar squabble results in a a 0-0-0 score we can at least add scalars
later.This is not quite that obvious I don't think. If
https://wiki.php.net/rfc/context_sensitive_lexer isn't ready in time for
7.0 and we don't need to reserve these for one of the STH RFCs then we
should hold off and do it alongside the context sensitive lexer change
or we are going to needlessly break a ton of code including Drupal8:https://github.com/drupal/drupal/blob/8.0.x/core/lib/Drupal/Component/Utility/String.php#L15
-Rasmus
I respect this opinion, though I disagree. I do agree that breaks in
backwards compatibility should not be taken lightly; I think we just
disagree on the magnitude of both the breaks and the gains.
Am 14.03.2015 um 10:21 schrieb Pavel Kouřil pajousek@gmail.com:
RFC Link: https://wiki.php.net/rfc/reserve_more_types_in_php_7
The proposal has changed from the original. It no longer reserves the
aliases out of the interest of reserving the smallest useful,
uncontroversial subset. Some people want to remove aliases for these
types so in the interest of being as uncontroversial as possible I am
no longer proposing to remove them.This will go into voting on March 15th unless something comes up
between now and then to persuade me otherwise.--
Hello,
why do you consider a "true" and "false" as a type? It's not a type. it's a
value?Regards
Pavel KourilThese aren't types. But useful for e.g. union types (int|false). [By the way they're internally handled as different types… but that's an implementation detail…]
Also, he doesn't call them anywhere types, it's just the title.
Bob
This is a solid plan. Vote this and everyone should +1 it, so if this
scalar squabble results in a a 0-0-0 score we can at least add scalars
later.This is not quite that obvious I don't think. If
https://wiki.php.net/rfc/context_sensitive_lexer isn't ready in time for
7.0 and we don't need to reserve these for one of the STH RFCs then we
should hold off and do it alongside the context sensitive lexer change
or we are going to needlessly break a ton of code including Drupal8:https://github.com/drupal/drupal/blob/8.0.x/core/lib/Drupal/Component/Utility/String.php#L15
Rasmus (and others),
How would you feel about emitting E_DEPRECATED
whenever one of
these[1] names is used for a class declaration? Emitting E_DEPRECATED
is less helpful but less painful. It's not my preference (just like
emitting E_DEPRECATED
for PHP 4 constructors was not my preference)
but ultimately I care about the eventual result. I'm happy to wait as
long as we've agreed to fix it eventually.
Of course, if a scalar types RFC passes most of these will be reserved
anyway. Right now it is a coin toss if Anthony's proposal will pass
(it keeps flipping back and forth).
[1] int, float, bool, string, true, false, null
Am 14.03.2015 um 10:21 schrieb Pavel Kouřil pajousek@gmail.com:
RFC Link: https://wiki.php.net/rfc/reserve_more_types_in_php_7
The proposal has changed from the original. It no longer reserves the
aliases out of the interest of reserving the smallest useful,
uncontroversial subset. Some people want to remove aliases for these
types so in the interest of being as uncontroversial as possible I am
no longer proposing to remove them.This will go into voting on March 15th unless something comes up
between now and then to persuade me otherwise.--
Hello,
why do you consider a "true" and "false" as a type? It's not a type. it's a
value?Regards
Pavel KourilThese aren't types. But useful for e.g. union types (int|false). [By the way they're internally handled as different types… but that's an implementation detail…]
Also, he doesn't call them anywhere types, it's just the title.
Bob
Hello,
a union type would be an union of types - so it should be int|bool,
shouldn't it? (Also, I don't personally like the idea of union types
in general, but it's not relevant to the current RFC, so I won't
comment more on that issue.)
Still, maybe the title of the RFC should change to "Reserve More
Keywords in PHP 7", so it's not misleading?
PS: Thanks for the info about internal stuff, didn't know about that. :)
Regards
Pavel Kouril
Am 14.03.2015 um 06:41 schrieb Levi Morrison:
RFC Link: https://wiki.php.net/rfc/reserve_more_types_in_php_7
The proposal has changed from the original. It no longer reserves the
aliases out of the interest of reserving the smallest useful,
uncontroversial subset. Some people want to remove aliases for these
types so in the interest of being as uncontroversial as possible I am
no longer proposing to remove them.This will go into voting on March 15th unless something comes up
between now and then to persuade me otherwise.
Sorry but I'm strictly against reserving any aliases, without directly
implementing some functionality behind them. This will block any
user-land workarounds for doing those features, while they maybe will
implemented versions after this reservation by the language itself. That
is no well behavior of a language.
For this reason -1 vote for me having some kind of Scalar Autoboxing
objects already implemented. Yes I would be able to rename for example
int object to MyInt but then I have to refactor all usages and have to
refactor again if the feature is finally in.
Regards,
--
DerOetzi
Hi
2015-03-14 6:41 GMT+01:00 Levi Morrison levim@php.net:
RFC Link: https://wiki.php.net/rfc/reserve_more_types_in_php_7
The proposal has changed from the original. It no longer reserves the
aliases out of the interest of reserving the smallest useful,
uncontroversial subset. Some people want to remove aliases for these
types so in the interest of being as uncontroversial as possible I am
no longer proposing to remove them.
After this change I would change my vote to -1, because I would like
the reserved type words to be consistent with those of the typecasts.
While I agree that we should maybe drop aliases in typecasts like
"real", I don't think it makes sense to reserve "Int" for class names,
when we don't reserve "Integer" etc.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Hi
2015-03-14 6:41 GMT+01:00 Levi Morrison levim@php.net:
RFC Link: https://wiki.php.net/rfc/reserve_more_types_in_php_7
The proposal has changed from the original. It no longer reserves the
aliases out of the interest of reserving the smallest useful,
uncontroversial subset. Some people want to remove aliases for these
types so in the interest of being as uncontroversial as possible I am
no longer proposing to remove them.After this change I would change my vote to -1, because I would like
the reserved type words to be consistent with those of the typecasts.
While I agree that we should maybe drop aliases in typecasts like
"real", I don't think it makes sense to reserve "Int" for class names,
when we don't reserve "Integer" etc.
I may open the vote with multiple options, then. I really don't care
about this detail. If people want the aliases that's reasonable, and
if they don't want them that's reasonable too.