[PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

On Sat, Oct 30, 2010 at 06:50, Daniel Jänecke <[email protected]> wrote:
>
> Well, isn't the problem here more people asking on IRC rather than using
> a search engine before? Renaming will not solve that.

In this case, one might argue that it would. Instead of "what's a
T_PAAMAYIM_NEKUDOTAYIM?" you would have, "WTF IS A T_DOUBLE_COLON
ERROR N Y R PHP DOODZ SO F'D UP ARGH LOLZ!!1!"

--
</Daniel P. Brown>
Network Infrastructure Manager
Documentation, Webmaster Teams
http://www.php.net/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

As a further reason, (not that I think that's it needed)

When doing anything vaguely specialist, e.g engineering, medicine, sport, you require a precise set of terminology so two or more people can communicate clearly. The result of this is that if you want to play in a domain, you must be prepared to learn and use domain specific language/terms/acronyms.

The double colon is example of this.

We can lead the horse to water, but we can't make him drink.

--
James Butler
Sent from my iPhone
>


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Fri, Oct 29, 2010 at 11:30:04PM -0700, Rasmus Lerdorf wrote:
> 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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 10/30/2010 05:50 AM, Daniel Jänecke wrote:
>
> On 30.10.2010 08:34, Chad Emrys wrote:
>
>> 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.
>>
> Well, isn't the problem here more people asking on IRC rather than using
> a search engine before? Renaming will not solve that.
>
> ~danielj
>
>
That is an easy one to argue: Yes it will.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 10/30/2010 09:55 AM, Daniel Brown wrote:
> On Sat, Oct 30, 2010 at 06:50, Daniel Jänecke<[email protected]> wrote:
>
>> Well, isn't the problem here more people asking on IRC rather than using
>> a search engine before? Renaming will not solve that.
>>
> In this case, one might argue that it would. Instead of "what's a
> T_PAAMAYIM_NEKUDOTAYIM?" you would have, "WTF IS A T_DOUBLE_COLON
> ERROR N Y R PHP DOODZ SO F'D UP ARGH LOLZ!!1!"
>
>
Most likely not, we don't get tons of questions about other parser
errors, unless the person refuses to read the error message to begin
with (Those can't be fixed, true. But this for those people that DO
read the messages, which is greater number than what you guys lead on)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 10/30/2010 03:46 AM, Mike Van Riel wrote:
> On 30 okt 2010, at 09:34, Chad Emrys <[email protected]> wrote:
>
>> On 10/30/2010 02:16 AM, Peter Lind wrote:
>>> On 30 October 2010 09:09, Mike Van Riel<[email protected]>
>>> wrote:
>>>
>>> * snip *
>>>
>>>
>>>> (additionally I wonder why people ask such a simple question on IRC
>>>> whilst
>>>> googling provides your answer faster..)
>>>>
>>> Most of the people coming to ##php on freenode asking questions like
>>> that have a hard time learning (on their own or at all) - they expect
>>> to be spoonfed. Changing the token name might lower the frequency of
>>> this particular question, but it would have no overall effect on the
>>> number of people coming to ask questions they could get answered in
>>> two seconds by google.
>>>
>>> Regards
>>> Peter
>>>
>>>
>> It's the same argument everyone else is giving, and really it all
>> comes down to this.:
>>
>> Nostalgia is valued over clarity and consistency.
>>
>> Do you guys REALLY want to claim that?
>
> If you are referring to my response, I believe I have given other
> arguments than your claim, as have others.
>
> The point is in the question: is it worth it?
>
> Do you think it is worth it to change something which works
> (functionally), has been there for 12 years and for the effort it
> takes to persuade people to want to change it?
>
> This all because people will have to google once in their carreer?
>
> Another solution might be to add a rule to an IRC bot to automatically
> provide the answer if the token name (and/or common misspellings) are
> mentioned. This would instantly solve the issue about support requests.
>
> Kind regards,
>
> Mike van Riel
I think it's more constructive to the language when we ask "Why Not?"
rather than "Why"? I already mentioned in my first email: It is worth it.

Automatic bot responses are prone to abuse.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Sat, Oct 30, 2010 at 12:35, Chad Emrys <[email protected]> wrote:
>
> Most likely not, we don't get tons of questions about other parser errors,
> unless the person refuses to read the error message to begin with (Those
> can't be fixed, true.  But this for those people that DO read the messages,
> which is greater number than what you guys lead on)

I have to say, you certainly are sure of yourself when it comes to
describing our opinions and actions, yet - aside from argue a point
that has little chance of succeeding here, as you can tell - you've
done nothing to give your point validity outside of your own
experience and interpretations.

You mentioned how great it was that PHP is FOSS, and that you'd
only have to bribe whomever is handling patch reviews and submissions.
Another great thing about FOSS: your right to fork.

--
</Daniel P. Brown>
Dedicated Servers, Cloud and Cloud Hybrid Solutions, VPS, Hosting
(866-) 725-4321
http://www.parasane.net/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

If it ain't broken don't fix it.

Change for the sake of it is a bad thing. It does things like introduce bugs etc.

Q1) is it broken?
Q2) if yes exactly what is broken
Q3) does the proposes fix solve the root cause?

I'm not sure changing the token name is the correct fix to people not knowing what the error means.

--
James Butler
Sent from my iPhone

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 10/30/2010 11:41 AM, Daniel P. Brown wrote:
> On Sat, Oct 30, 2010 at 12:35, Chad Emrys<[email protected]> wrote:
>
>> Most likely not, we don't get tons of questions about other parser errors,
>> unless the person refuses to read the error message to begin with (Those
>> can't be fixed, true. But this for those people that DO read the messages,
>> which is greater number than what you guys lead on)
>>
> I have to say, you certainly are sure of yourself when it comes to
> describing our opinions and actions, yet - aside from argue a point
> that has little chance of succeeding here, as you can tell - you've
> done nothing to give your point validity outside of your own
> experience and interpretations.
>
> You mentioned how great it was that PHP is FOSS, and that you'd
> only have to bribe whomever is handling patch reviews and submissions.
> Another great thing about FOSS: your right to fork.
>
>
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).

Forking won't fix this particular problem.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 10/30/2010 11:43 AM, James Butler wrote:
> If it ain't broken don't fix it.
>
> Change for the sake of it is a bad thing. It does things like introduce bugs etc.
>
> Q1) is it broken?
> Q2) if yes exactly what is broken
> Q3) does the proposes fix solve the root cause?
>
> I'm not sure changing the token name is the correct fix to people not knowing what the error means.
>
> --
> James Butler
> Sent from my iPhone
>
Q1) yes, it is broken, people have to Google or ask around for a very
unclear error message when for the most parts errors are (and should be)
self explanatory.

Q2) Two things are broken: Either the token is named badly, or the
token names shouldn't show up in error messages at all and be replaced
with something a bit more friendly.

Q3) those two fixes above would probably fix that, yes.

What is so hard to believe when people see UNEXPECTED T_DOUBLE_COLON on
LINE 23 they are gonna look for a double colon on line 23? because they DO.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Sat, Oct 30, 2010 at 12:47, Chad Emrys <[email protected]> wrote:
>
> 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.

--
</Daniel P. Brown>
Dedicated Servers, Cloud and Cloud Hybrid Solutions, VPS, Hosting
(866-) 725-4321
http://www.parasane.net/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 10/30/2010 11:58 AM, Daniel P. Brown wrote:
> On Sat, Oct 30, 2010 at 12:47, Chad Emrys<[email protected]> wrote:
>
>> 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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 30 October 2010 19:18, Chad Emrys <[email protected]> wrote:
> On 10/30/2010 11:58 AM, Daniel P. Brown wrote:
>>
>> On Sat, Oct 30, 2010 at 12:47, Chad Emrys<[email protected]>  wrote:
>>
>>>
>>> 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.
>

Why not throw your weight behind http://wiki.php.net/rfc/lemon ? Seems
to me that might get a lot more traction.

Regards
Peter

--
<hype>
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
</hype>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Sat, Oct 30, 2010 at 12:18 PM, Chad Emrys <[email protected]> wrote:
>  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.

As one of those people who "use PHP", after the first time googling
it, I haven't needed it. It's one of those things about the language
that's interesting.

If you're going to complain about how someone has to learn something
about another culture, why not take a step back and consider those
throughout the world whose native language is something other than
English have to try to translate what it does.

Also, as one who also answers other's questions (although not IRC,
because its my experience most people asking questions on there are
dbags), I find that complaints regarding PHP's ambiguity in naming
conventions and variable order (which is slowly being fixed, and is
greatly appreciated) far, far outnumber the complaints regarding
T_PAAMAYIM_NEKUDOTAYIM. Actually, I never hear complaints about
T_PAAMAYIM_NEKUDOTAYIM, just questions about what it is by people
who'd rather be told than find out for themselves. And, when they find
out, the answer is usually something like "Oh, neat."

And, what sort of cooperation do you expect to get when your first
line is "WTF is T_PAAMAYIM_NEKUDOTAYIM?". That's akin to finding
multiple languages on your tax forms and exclaiming "WTF is this doing
here!?"

--
Jack Timmons
@_Codeacula
Trollfree: 8503290326

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Sat, 30 Oct 2010 12:44:41 -0500
Jack Timmons <[email protected]> wrote:
> Also, as one who also answers other's questions (although not IRC,
> because its my experience most people asking/*answering* questions on
> there are dbags),

FTFY.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Are you supporting users who you provide a shared hosting embodiment too, and do you control binary installations on the enviroments? If so then possibly patching source for you installs maybe the easiest and quickest solution.
If we knew the nature of your support requirements, then we could possibly suggest a better solution or be won round. (although internals isn't the place for that really)

This is not meant to bait but possibly an improvement in your support process or docs might yield a solution?

--
James Butler
Sent from my iPhone

On 30 Oct 2010, at 17:51, "Chad Emrys" <[email protected]> wrote:

> On 10/30/2010 11:43 AM, James Butler wrote:
>> If it ain't broken don't fix it.
>>
>> Change for the sake of it is a bad thing. It does things like introduce bugs etc.
>>
>> Q1) is it broken?
>> Q2) if yes exactly what is broken
>> Q3) does the proposes fix solve the root cause?
>>
>> I'm not sure changing the token name is the correct fix to people not knowing what the error means.
>>
>> --
>> James Butler
>> Sent from my iPhone
>>
> Q1) yes, it is broken, people have to Google or ask around for a very
> unclear error message when for the most parts errors are (and should be)
> self explanatory.
>
> Q2) Two things are broken: Either the token is named badly, or the
> token names shouldn't show up in error messages at all and be replaced
> with something a bit more friendly.
>
> Q3) those two fixes above would probably fix that, yes.
>
> What is so hard to believe when people see UNEXPECTED T_DOUBLE_COLON on
> LINE 23 they are gonna look for a double colon on line 23? because they DO.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 10/30/2010 01:02 PM, James Butler wrote:
> Are you supporting users who you provide a shared hosting embodiment too, and do you control binary installations on the enviroments? If so then possibly patching source for you installs maybe the easiest and quickest solution.
> If we knew the nature of your support requirements, then we could possibly suggest a better solution or be won round. (although internals isn't the place for that really)
>
> This is not meant to bait but possibly an improvement in your support process or docs might yield a solution?
>
> --
> James Butler
> Sent from my iPhone
>
> On 30 Oct 2010, at 17:51, "Chad Emrys"<[email protected]> wrote:
>
>
No I support a general PHP support community. We help everywhere from
beginners to seasoned experts, and probably help around hundreds of
people a day.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 10/30/2010 12:57 PM, Mark Skilbeck wrote:
> On Sat, 30 Oct 2010 12:44:41 -0500
> Jack Timmons<[email protected]> wrote:
>
>> Also, as one who also answers other's questions (although not IRC,
>> because its my experience most people asking/*answering* questions on
>> there are dbags),
>>
> FTFY.
>
>
That's just rude, dude.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 10/30/2010 12:44 PM, Jack Timmons wrote:
> On Sat, Oct 30, 2010 at 12:18 PM, Chad Emrys<[email protected]> wrote:
>
>> 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.
>>
> As one of those people who "use PHP", after the first time googling
> it, I haven't needed it. It's one of those things about the language
> that's interesting.
>
> If you're going to complain about how someone has to learn something
> about another culture, why not take a step back and consider those
> throughout the world whose native language is something other than
> English have to try to translate what it does.
>
> Also, as one who also answers other's questions (although not IRC,
> because its my experience most people asking questions on there are
> dbags), I find that complaints regarding PHP's ambiguity in naming
> conventions and variable order (which is slowly being fixed, and is
> greatly appreciated) far, far outnumber the complaints regarding
> T_PAAMAYIM_NEKUDOTAYIM. Actually, I never hear complaints about
> T_PAAMAYIM_NEKUDOTAYIM, just questions about what it is by people
> who'd rather be told than find out for themselves. And, when they find
> out, the answer is usually something like "Oh, neat."
>
> And, what sort of cooperation do you expect to get when your first
> line is "WTF is T_PAAMAYIM_NEKUDOTAYIM?". That's akin to finding
> multiple languages on your tax forms and exclaiming "WTF is this doing
> here!?"
>
>
I'm not arguing about learning another culture. The argument is that an
error message that should be straight forward, isn't.

I wouldn't be here if the error message was something like: unexpected
T_PAAMAYIM_NEKUDOTAYIM on line 23 (PAAMAYIM NEKUDOTAYIM is hebrew for
double colon because a lot of great Israelites helped make what PHP is
today) :p

Also that first line is just a sample of what I got to deal with on a
day to day basis.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 10/30/2010 12:44 PM, Peter Lind wrote:
> On 30 October 2010 19:18, Chad Emrys<[email protected]> wrote:
>
>> On 10/30/2010 11:58 AM, Daniel P. Brown wrote:
>>
>>> On Sat, Oct 30, 2010 at 12:47, Chad Emrys<[email protected]> wrote:
>>>
>>>
>>>> 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.
>>
>>
> Why not throw your weight behind http://wiki.php.net/rfc/lemon ? Seems
> to me that might get a lot more traction.
>
> Regards
> Peter
>
>
I actually know Etienne, he does spend some of his time fighting the
good fight of supporting PHP :p. Anyway he has said the lemon parser
project is going kind of slow as it is proving to be more difficult
because some of the weirdness in PHP. (Don't ask me what that means.)
Maybe more help should be put into that effort?

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 30 October 2010 22:13, Chad Emrys <[email protected]> wrote:

*snip*

>
> I actually know Etienne, he does spend some of his time fighting the good
> fight of supporting PHP :p.  Anyway he has said the lemon parser project is
> going kind of slow as it is proving to be more difficult because some of the
> weirdness in PHP. (Don't ask me what that means.) Maybe more help should be
> put into that effort?

That was my point: perhaps that would be a less futile fight than
trying to persuade people that t_paamayim_nekudotayim should be
renamed.

Regards
Peter

--
<hype>
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
</hype>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 10/30/2010 03:21 PM, Peter Lind wrote:
> On 30 October 2010 22:13, Chad Emrys<[email protected]> wrote:
>
> *snip*
>
>
>> I actually know Etienne, he does spend some of his time fighting the good
>> fight of supporting PHP :p. Anyway he has said the lemon parser project is
>> going kind of slow as it is proving to be more difficult because some of the
>> weirdness in PHP. (Don't ask me what that means.) Maybe more help should be
>> put into that effort?
>>
> That was my point: perhaps that would be a less futile fight than
> trying to persuade people that t_paamayim_nekudotayim should be
> renamed.
>
> Regards
> Peter
>
>

Perhaps you are right. Most constructive thing said in this thread yet.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Oct 30 19:44:08, Peter Lind wrote:
> On 30 October 2010 19:18, Chad Emrys <[email protected]> wrote:
> > On 10/30/2010 11:58 AM, Daniel P. Brown wrote:
> >>
> >> On Sat, Oct 30, 2010 at 12:47, Chad Emrys<[email protected]>  wrote:
> >>
> >>>
> >>> 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.
> >
>
> Why not throw your weight behind http://wiki.php.net/rfc/lemon ? Seems
> to me that might get a lot more traction.

lemon would indeed get rid of actual "names" for such tokens, and would
rather display "unnexpected ::".

The problem with lemon is that it turns out to still be a tad bit slower
than yacc, with some complications on the grammar side (the compiler
helper functions were made for yacc). So unless there is a major speedup
breakthrough, it won't happen in a near future, sadly.

>
> Regards
> Peter
>
> --
> <hype>
> WWW: plphp.dk / plind.dk
> LinkedIn: plind
> BeWelcome/Couchsurfing: Fake51
> Twitter: kafe15
> </hype>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--
Etienne Kneuss
http://www.colder.ch

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 10/30/2010 03:32 PM, Etienne Kneuss wrote:
> lemon would indeed get rid of actual "names" for such tokens, and would
> rather display "unnexpected ::".
>
> The problem with lemon is that it turns out to still be a tad bit slower
> than yacc, with some complications on the grammar side (the compiler
> helper functions were made for yacc). So unless there is a major speedup
> breakthrough, it won't happen in a near future, sadly.
>
>

So does that leave us back to square 1 with replacing the token name? Or
is there another way that error messages can be tweaked to not show
actual token names?

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

From a completely separate stand point. The ability to customise what token names show up as in an error seems like a much better solution

--
James Butler
Sent from my iPhone

On 30 Oct 2010, at 21:41, "Chad Emrys" <[email protected]> wrote:

> On 10/30/2010 03:32 PM, Etienne Kneuss wrote:
>> lemon would indeed get rid of actual "names" for such tokens, and would
>> rather display "unnexpected ::".
>>
>> The problem with lemon is that it turns out to still be a tad bit slower
>> than yacc, with some complications on the grammar side (the compiler
>> helper functions were made for yacc). So unless there is a major speedup
>> breakthrough, it won't happen in a near future, sadly.
>>
>>
>
> So does that leave us back to square 1 with replacing the token name? Or
> is there another way that error messages can be tweaked to not show
> actual token names?
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Sat, Oct 30, 2010 at 3:10 PM, Chad Emrys <[email protected]> wrote:
> I'm not arguing about learning another culture. The argument is that an
> error message that should be straight forward, isn't.

You misunderstand my point.

It isn't straightforward for -you- because that isn't your native
language. Thus the cultural point. But if switched to
"T_DOUBLE_COLON", then others who don't know English could then argue
it isn't straight forward.

It's an entirely pedantic point to argue, I agree, but thus far you
entire complain was because it isn't in English, and you want it
changed so you "don't have to hear about it constantly". The fact is,
it says "double colon" in a different language, so aside from
translation there's nothing wrong with it at all.

Magic would be internationalizing the error messages, but then there
will be someone whose language doesn't have a version.

--
Jack Timmons
@_Codeacula
Trollfree: 8503290326

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Sat, Oct 30, 2010 at 07:50:29PM -0500, Jack Timmons wrote:
> On Sat, Oct 30, 2010 at 3:10 PM, Chad Emrys <[email protected]> wrote:
> > I'm not arguing about learning another culture. The argument is that an
> > error message that should be straight forward, isn't.
>
> You misunderstand my point.
>
> It isn't straightforward for -you- because that isn't your native
> language. Thus the cultural point. But if switched to
> "T_DOUBLE_COLON", then others who don't know English could then argue
> it isn't straight forward.
>
> It's an entirely pedantic point to argue, I agree, but thus far you
> entire complain was because it isn't in English, and you want it
> changed so you "don't have to hear about it constantly". The fact is,
> it says "double colon" in a different language, so aside from
> translation there's nothing wrong with it at all.
>
> Magic would be internationalizing the error messages, but then there
> will be someone whose language doesn't have a version.

My native language isn't English and isn't Hebrew. I'm being fucked twice!

A lot of people (including me) don't know Hebrew nor care about it. The reason
for keeping this error message seems to be to teach people a lesson about how
difficult it is for some people to learn a new natural language.

It's obvouisly your right to do so. But what you'r saying here is just
nonsense.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Colon? Be doubly sure to eat a healthy fiber enriched diet with plenty of water!

Regards,
Philip


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 10/30/2010 07:50 PM, Jack Timmons wrote:
> On Sat, Oct 30, 2010 at 3:10 PM, Chad Emrys<[email protected]> wrote:
>
>> I'm not arguing about learning another culture. The argument is that an
>> error message that should be straight forward, isn't.
>>
> You misunderstand my point.
>
> It isn't straightforward for -you- because that isn't your native
> language. Thus the cultural point. But if switched to
> "T_DOUBLE_COLON", then others who don't know English could then argue
> it isn't straight forward.
>
> It's an entirely pedantic point to argue, I agree, but thus far you
> entire complain was because it isn't in English, and you want it
> changed so you "don't have to hear about it constantly". The fact is,
> it says "double colon" in a different language, so aside from
> translation there's nothing wrong with it at all.
>
> Magic would be internationalizing the error messages, but then there
> will be someone whose language doesn't have a version.
>
>
That wouldn't bother me if it was in a different language as long as all
tokens are consistently in another language. The fact there is ONE
token in Hebrew is inconsistent and not straight forward.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php