[PHP-INTERNALS] Make primitive type names reserved words (Was: Re: [PHP-DEV] [RFC] 5.4 features for vote (long))

There's going to be a ton of code in the wild that will break if primitive
types become reserved words.

Well, I generally think that PHP should be less strict about reserved
keywords. The number
of reserved keywords increases with every further release of PHP. For
example PHP 5.4
introduces "trait" and "insteadof". PHP 5.3 introduced even more. Every new
keyword PHP
introduces both breaks old code and reduces the naming possibilities for
classes and methods.

I don't think that it's possible to refrain from adding further keywords.
The language grows and
with it the list of keywords.

But I do think that it should be possible to prevent these additions from
breaking old code or
restricting userland naming.

E.g. Writing

class Evaluator {
public function eval() {

}
}

Does in no way create an ambiguity with the eval language construct PHP
implements.

But still PHP doesn't allow writing the above code. It would make sense to
allow the
use of the keyword in such situations. Actually PHP already does this in one
place:
The token after T_OPJECT_OPERATOR is never interpreted as a keyword. I.e.
one can
write $this->eval() (and define a magic __call method for 'eval').

I don't know whether this is actually possible, but I've at least already
seen a patch
(http://pear.php.net/~greg/smarter_lexer.patch.txt) for the methodname case
linked
from a feature request (https://bugs.php.net/bug.php?id=28261).

MfG Nikita

Hi!
If this patch indeed works, I don't see why we couldn't add it. Needs to
be extensively checked, but if it works - why not?

Very good find of an inconsistency. Does the testsuite reveal something
strange with that patch?

Am 10.07.11 19:41 schrieb "Nikita Popov" unter <nikita.ppv@googlemail.com>:

I didn't test that patch, just found it in the bugtracker.
cellog@php.net would be a better person to ask, as he wrote it. But
just from glancing at it I could imagine that it would break
token_get_all() as CG(active_class_entry) wouldn't be set
appropriately (though that's just a guess).

MfG Nikita

Hi everybody,

Attached is the patch against current trunk with a testcase, tokenizer
tests do not break. If nobody objects, could somebody with commit access
to Zend could commit this patch?

With regards,
Lars

Am 10.07.11 23:51 schrieb "Nikita Popov" unter <nikita.ppv@googlemail.com>:

And again, as .txt

Am 11.07.11 00:36 schrieb "Lars Strojny" unter <lars@strojny.net>:

Wait, wait.

Tokenizer surely is broken, it will identify a method name 'include'
as T_INCLUDE.

Hi,

2011/7/10 Nikita Popov <nikita.ppv@googlemail.com>:
Yes, you are right. We cannot rely on CG(active_class_entry) data.

I'm against this patch, because we will just add more inconsistency.
Allow reserved words in method name, OK. But what about class
name/namespace name etc?

And in the begin of thread the topic was type name as class name,
nothing to do with methods.

Hi Felipe,

Am 11.07.11 00:41 schrieb "Felipe Pena" unter <felipensp@gmail.com>:
Good argument, namespace names and class names should be treated similar.
Would you object a patch doing it for class names, interface names and
namespaces?

With regards,
Lars

Hi,

2011/7/10 Lars Strojny <lars@strojny.net>:
To handle the class name in a method call turn out tricky. For example:

include::list();

When matching 'include' we have to check if it's (ignoring whitespaces
and comments) an 'include ".."', 'include(...)', 'include::'. This
will require massive use of lookahead, which lead to handling trailing
context in the scanner, for each current reserved words. It's not so
simple.

Using re2c we can to match 'include' only if followed by something
using the r/s syntax, but this doesn't solve all. As the one could
use: include /* foobar */ ::list() - and even being quite weird, it
should keep working.

Complexity++

Hi!
Agreed, class names would be trouble. Same with any token that can be
first in the expression/statement. However, I think methods might be
relatively safe, if we make tokenizer, etc. work properly.

For a method this is correct. But for a normal function this is
different:

<?php
function eval() {
}
eval(); // will call the language construct
?>

And i consider it "strange" to allow different names for functions and
methods. And yes I'm aware that
$eval = 'eval'; $eval();
would call the function.

I fear consistency issues.

johannes

But what about this?

namespace Foo
{
function eval($name)
{
echo $name;
}

eval('matthew');
}

The manual doesn't really differentiate between language constructs and
functions, and as such, I can see somebody reading the namespace section
of the manual and feeling this should be valid -- but currently, it
results in a parse error.

It seems to me we need a context-sensitive lexer.

Hi!
We probably can do it so String is OK, but string is not. But yes, if we
ever have scalar typing, it would conflict with such types I imagine.
But this may be a problem for whoever would venture to create that
patch, if it ever happens.
I don't think there's such thing in PHP as namespaced keywords. Keywords
are processed by the language parser, which knows next to nothing of
namespaces.
We could, maybe, prohibit creation of classes with names identical to
type names, which is different from making it reserved word, and on that
stage we know the full class name.

I think that's a bad idea. The point of namespaces is to allow us to
override classes (and functions, and constants) within that namespace.
If I can't do this:

namespace Foo
{
class String
{
}
}

then I'd consider the implementation too restrictive.

the parser is a little bit dumb, and the namespaces isn't really first
class citizens in php AFAIK, so it's not a deliberate restriction imo,
just a technical, which could be solved.

[snip]
This is exactly my concern.
The parser being dumb wouldn't be a reason to make code which works
fine on 5.3, break on 5.4 and then again working on 5.5 because of
words being keyworded for the sake of "a future implementation" which
doesn't explain whether it would break that kind of namespaced
classes.

Regards,
Patrick

Are you suggesting to make class names case sensitive now? I don't think
that that's what you meant, but it clearly shows that the "probably can"
is "cannot" in your sentence above.

cheers,
Derick

hi,

As I could agree on this fact, I can't find any existing project
having int(eger), float&co as class, namespaced or not. Do you have
any example at hand?

Cheers,

https://github.com/search?type=Code&language=PHP&q=%22class+int%22&repo=&langOverride=&x=0&y=0&start_value=1

not too many though.

ZF and ODM do it and inside namespace. We should be sure that these
cases still work, as NS exists for this exact purpose.

Cheers,

Try that for String and it reveals a different picture. Horde 3 used
that too FWIW.

Jan.

Even the php5 versions of Horde? That's rather bad given the so strong
and loud warnings we gave about using common names w/o namespace, by
the time of the date problem.

Cheers,

No, of course not. That's why I didn't voice an opinion, I just found
it worth mentioning. Horde 3 users can stick with PHP 5.3, while Horde
4 users are not affected at all.

It's still used in a lot of other code though, see the github search.

Jan.

hi,

As of now I do not think we should allow this change, whether the RFC
is accepted or not does not matter as it will badly break BC. Unless
there is a patch allowing this change without affecting existing code
(main point being namespaced code working smoothly), this RFC should
be rejected.

Cheers,

With these new elements, I agree the fact that the RFC should be
rejected. But maybe we can add new magic methods, such as: __toBool(),
__toInt(), __toFloat() etc. User can use int(), float() etc. if he
needs/wants to, and we are always able to do same things (e.g. adding
future features).
Moreover, PHP has a dynamic typing system. Having tokens as reserved
keywords appears obviously logical to me, but why having type names as
reserved keywords? Sounds like we do not assume our “type position”.
That's why adding magic methods looks like a better way to solve this
problem.

Thougs?

Best regards.


PS: I cannot change my vote on https://wiki.php.net/todo/php54/vote, is
it a known issue?

if you don't have @php.net account, or 'voting' group membership in
the wiki, then you cannot vote, or change your vote.
this change was made yesterday to fix the issue that the technical
restriction for the voting in the wiki isn't in pair with our accepted
voting RFC.

And how can I join the “voting” group :-) ?

Hi,
I agree with that. Perhaps the first step is to raise an E_NOTICE or
E_STRICT and in the next major release, the E_PARSE.

Cheers,
Bruno

I think this change has too much of an impact on backward compatibility.
As long as we don't have a concrete implementation, I think we should
let string, int not be reserved words. Argumentes were already presented.

ps.: Pierre you might want to consider changing your vote in the wiki

This thread is an excellent example why attempting to reach consensus
by discussing things is important.
Voting should be considered as an desperate last resort, not the
primary mechanism.

http://producingoss.com/en/consensus-democracy.html has several very
related points.

-Hannes

Hi!
That was the idea, but the problem is people ignore discussions on the
list and only wake up when vote is to be closed soon :)

And each topic deserves its own thread, whereas this [original] thread lumped 10 separate topics together.

Regards,
Philip

hi Hannes,

On Wed, Jul 13, 2011 at 6:35 PM, Hannes Magnusson
wrote:
I disagree and this exact issue shows that the voting and controlling
is actually working well, very well. As it is covered by the two
recently adopted RFCs.

Cheers,

I'm not sure how you come to the conclusion that it is working well.
This particular change is clearly not feasible for 5.4, yet the votes
are 37-19 for doing it right now.

-Rasmus

Maybe read my reply in this exact thread?

I said that due the BC problem, discovered or discussed later, forces
us to reject this RFC.

Cheers,

What do you mean discovered or discussed later? Anybody who bothered to
read the RFC should have seen the BC problem. It's not like it was
hiding in small letters somewhere.

And most of the other votes are unanimous which make them rather
pointless as well.

-Rasmus

We have some issues here. One is that I can't find the RFC for this
proposal. Many of these votes are made out of the 5.4 todos instead of
having clear and obvious (as you wish) RFCs. That was a mistake. But
that's a new thing, we are learning.

However, while making these primitives keywords sounded like a good
and easy step, not being able to use them inside a namespace is a not
acceptable BC break. It was also not obvious that NS won't be
supported.
Are you saying that widely approved thing are pointless or we could
have foreseen the results for each of them? Better to have a vote and
got a massive support than nothing and sit in the middle of nowhere
forever.

Cheers,

I'm saying that many of these in the past were handled by a, "Hey guys,
any objections to adding E_STRICT to E_ALL in 5.4?" email which would
get a couple of, "go for it" replies and no objections, followed by the
change being committed. To me the voting is only needed when we have
trouble reaching a quick consensus and not for every little thing.

-Rasmus

Yes, got it, they were rhetorical questions :). However doing it this
way spares us time in the long run. While one or another proposal
could get large and immediate adoption, it makes the whole thing
clearer for the developers not following internals@ daily or to our
users.

Right, but these folks that don't follow the discussions are the same 37
people who voted for the Primitives change. How is that helpful?

I think a vote should be a big deal. Anything that comes up for a vote
should have a healthy discussion and an extremely well-fleshed out RFC
which includes both sides of the argument culled from the healthy
discussion. And the voting page should heavily encourage people to
actually read the RFC in its entirety before voting.

-Rasmus

Many of the votes there are not from developers. We have explained
what happened earlier this week. I don't think it is necessary to
discuss this problem again here as it is fixed (Tyrael implemented the
voting ACL and is now used).
Fully agreed and that's what the voting RFC says as well. And why I
said that simple todos should not have been submitted to votes except
those requiring RFC due to their complexity or whatever else.

Cheers,

ah forgot to mention that indeed not all todos should have be done via
a RFC, that would not help us, not at all. But the primitive one, for
example, must have one.