rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

The fact they have to google to figure out what it means, the error
message fails at it's purpose. (Realistically it'll take longer than a
second unless you got google hot keyed to your log reader). I Liked
Stefan's idea in the previous thread to not put token names in the error
messages anymore and replace them with something more meaningful for the
user. However, since that never happened, this is a better/easier
alternative for now. How many total hours of googling will we save
developers for a 10 sec grep and replace? (not sure if it's that easy,
but for the sake of the argument).

I can see only positives by switching it out. can someone give me a
light on how much it would actually cost to do that? Some negatives? I
don't see the argument given to be entirely helpful because it's exactly
what I am trying to point out as a problem, and the reason why we should
change it.

There are two reasons this term will stay. It is a tip of the hat to
the amount of PHP work that came out of Israel, and it is a good
reminder that there are a lot of other languages in the world. People
whose first language is not English, myself included, are forced to work
with unfamiliar terms every day. I wouldn't mind having a few more
non-English identifiers in PHP actually.

Well, and a third reason, I like it.

-Rasmus

Well Rasmus, I wish you would hang out more in ##php on freenode. (I
see you there every so often) But we do get that question about that
thing a lot. And even some rage, and I have to cool them off with all
the reasons you and Andi are giving me right now. But I am not
convinced nostalgia or "teaching the English speakers a lesson" is a
good reason to keep around a confusing error message.

with unfamiliar terms every day. I wouldn't mind having a few more
non-English identifiers in PHP actually.

I don't know if i can make suggestions as an outsider. However, i really like
the dutch language and it would be really cool if T_WHILE would be replaced
with T_TERWIJL.

Hi!

I can see only positives by switching it out. can someone give me a
light on how much it would actually cost to do that? Some negatives? I

It would probably require bribing all the opponents, so the cost would
be in high six digits (in $US) I guess.
Good thing this is FOSS! I only have to bribe who ever is approving
patches/commits these days.

what I am trying to point out as a problem, and the reason why we should

It's not a problem. A very mild irritation at best.
See my original message, you don't do enough support. :p

It's not that I'm that sure of myself, it's that I believe that my opinion
has merit, and I keep seeing the exact same argument over and over again
that I believe is not a very good argument (They can just google it thing).
Some other people have provided other arguments as well and those are more
valued. (Though I don't think they are strong enough reasons yet NOT to do
it).

 It does have merit --- to you, and perhaps a few others.

Hopefully without sounding like I'm ridiculing you (it's not my
intent), have you seriously considered this at all, and are you
realizing that it's just not going to happen at this time? I mean, if
you submitted a request or implementation proposal for an INI-based
option to switch between token strings and expanded help messages,
that would likely receive more serious attention than the dismissive
responses and formed opinions of your own insight as based upon this
discussion.

Forking won't fix this particular problem.

 Well, if your statement about how no one here who disagrees with

you does "enough support" (which is, quite frankly, an asinine
assessment), then an equal rebuttal will be that you do not know
enough about the inner workings of the software you claim to support,
nor the culture of the group who maintains it.

 You're taking a minor annoyance and trying to convince the masses

• and indeed the "powers that be" - that it is tantamount to Y2K38.
  Again, I'm really not trying to insult you or your original opinion
  here, Chad, but the continued arguments are almost coming off as silly
  now.

If you haven't noticed, I am a bit stubborn, yes it's a problem. When I
submitted this proposal, I have to at least try to plant a bug in their
brain that perhaps, they are being to hasty on dismissing this
argument. True, I do not know a lot about this particular culture that
maintains PHP. I just know the bigger culture of those who use PHP, and
some of them are quite annoyed by the dismissive nature of the
maintainers who are quite at odds to what the majority of the community
want or needs. And I am sort of glad to annoy those who are overly
dismissive, and hopefully ploy the one's who are on the fence.

No one said I was good at politics. But the fact one has to play the
politics game here to get anything worth while doesn't really phase me.

Now I am starting to find this argument straying from the point. I
don't believe attacking me personally or me attacking the nature of this
mailing list really has to do with the subject line.

-----Oorspronkelijk bericht-----
Van: Stan Vass [mailto:sv_forums@fmethod.com]
Verzonden: maandag 1 november 2010 10:19
Aan: internals@lists.php.net
Onderwerp: [SPAM] Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to
T_DOUBLE_COLON
Urgentie: Laag

It's amazing to me this has become such a long discussion. The facts
are
simple:

1. People don't ask for the other parse errors even half as often as
   they as for T_PAAMAYIM_NEKUDOTAYIM
2. They do so because it looks like gibberish to them, so it looks
   unlikely to be a common thing you can Google, nor it gives something
   recignizable to start with
3. Yes, to all who are not sure, more people know English than Hebrew.
4. Yes, we all acknowledge it's an easter egg joke that refers to the
   creators of PHP. But that particular joke has outworn its welcome in
   the community after repeatedly causing support issues.

T_DOUBLE_COLON already exists as a constant in userland, so the jump
to it won't be an epic change. Let's do it as a proof that we're not a
nerd gridlock bound to argue forever about even the most minor and
obviously positive changes PHP can implement.

Stan Vass

--
To unsubscribe,
visit: http://www.php.net/unsub.php

Come on people, what exactly is the problem with a once-in-a-lifetime investment of 5 seconds of your time to google some stupid error message. Something you, as a developer, spend your life doing.

Please, stop complaining about a minor (yes, it is minor, use the fricking search engine!) annoyance and accept php's heritage.

And please understand, I do get where all the opponents are coming from, it is an unnecessary complicated error message (I agree that the language argument is a moot point, in the world of internet and programming in particular, English is the standard), but you google it once in your life and then you 'forget' about it. And if you can't remember the meaning of something like that, I hardly doubt you'd be a decent programmer anyway.

Regards,
Dennis Haarbrink

Stan Vass wrote:

It's amazing to me this has become such a long discussion. The facts are
simple:

1. People don't ask for the other parse errors even half as often as
   they as for T_PAAMAYIM_NEKUDOTAYIM
2. They do so because it looks like gibberish to them, so it looks
   unlikely to be a common thing you can Google, nor it gives something
   recignizable to start with
3. Yes, to all who are not sure, more people know English than Hebrew.
4. Yes, we all acknowledge it's an easter egg joke that refers to the
   creators of PHP. But that particular joke has outworn its welcome in the
   community after repeatedly causing support issues.

T_DOUBLE_COLON already exists as a constant in userland, so the jump to
it won't be an epic change. Let's do it as a proof that we're not a nerd
gridlock bound to argue forever about even the most minor and obviously
positive changes PHP can implement.

Makes sense, just alias it and change the error message thus keeping bc.