Class name clashing

php.internals

Ralph Schindler

19 years ago
Is it still the position of internals that reserved words cannot be used as method names or class names? I need this to work <? class Case { /*.... methods and properties ....**/ } but PHP refuses to allow it. Please tell me someone is listening. -ralph

Stanislav Malyshev

19 years ago
> Is it still the position of internals that reserved words cannot be used > as method names or class names?
Why allow it? It would probably require substantial change in the parser, and what for?
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/

Ralph Schindler

19 years ago
Stanislav Malyshev wrote:
>> Is it still the position of internals that reserved words cannot be >> used as method names or class names? > > Why allow it? It would probably require substantial change in the > parser, and what for? >
I guess so that we can have a language that will be able to model real world problems... instead of the real world changing the name of the problem to fit the language. Its super frustrating when so many common words are marked as 'php scanner reservered' even when my context of use is completely different. Or, how about creating a language thats always striving to be better.. With the adoption of PHP5 also comes the increased adoption of OOP.. and this issue is a speed bump. Anyway, I write so that perhaps, maybe, just maybe, someone might want to see whats involved instead of simply writing off this request.... Thanks, -ralph

Stanislav Malyshev

19 years ago
> I guess so that we can have a language that will be able to model real > world problems... instead of the real world changing the name of the > problem to fit the language.
Language has its rules. Keywords are one of the rules. I, for example, am annoyed that in English you have to put this silly "a" and "the" everywhere, while so many real languages live perfectly well without it. If you want to argue how English is unfit to represent real world problems, reread "Who's on first base" sketch :) PHP has similar problems - some real world cases would have to add one or two letters so that it won't be confusing to the parser. Terrible, I agree, but that's what we have.
> Or, how about creating a language thats always striving to be better..
Name one language that strives to be worse. Your better is apparently different from other's better and also from what's possible and feasible to do.
> With the adoption of PHP5 also comes the increased adoption of OOP.. and > this issue is a speed bump.
No it isn't. I can see no single serious reason why the class must be named Case or you have to move to Smalltalk or give up OOP altogether. It's a minuscule annoyance at best.
> Anyway, I write so that perhaps, maybe, just maybe, someone might want > to see whats involved instead of simply writing off this request....
What's involved is probably changing language parser, not sure even current flex/yacc combo can do it.
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/

Richard Quadling

19 years ago
On 08/03/07, Stanislav Malyshev <stas@zend.com> wrote:
> Language has its rules. Keywords are one of the rules. I, for example, > am annoyed that in English you have to put this silly "a" and "the" > everywhere, while so many real languages live perfectly well without it.
At least 'a' and 'the' are not gender specific! In french, (http://www.french-linguistics.co.uk/grammar/le_or_la_in_french.shtml) - "you've just got to remember!" which is which! And with so many things about language, there are oddities! e.g. "Richard and Sally". Now, if you wanted to increase the gaps around the "and" you could quite legitimately say, "I would like a bigger gap between Richard and and and and and Sally".
-- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!"

Greg Beaver

19 years ago
Stanislav Malyshev wrote:
> No it isn't. I can see no single serious reason why the class must be > named Case or you have to move to Smalltalk or give up OOP altogether. > It's a minuscule annoyance at best. > >> Anyway, I write so that perhaps, maybe, just maybe, someone might want >> to see whats involved instead of simply writing off this request.... > > What's involved is probably changing language parser, not sure even > current flex/yacc combo can do it.
sure. All that would be needed is a new rule for each keyword: T_CLASS T_CASE in addition to T_CLASS T_STRING PITA, but possible :). Also possible with flex would be to enter a new state when T_CLASS is found, and return T_STRING for any text. However, I wouldn't want to be the one who implements this, when you can simply add a _ to the class name or use a longer descriptive classname like "UseCase" or "CaseOfVodka" or whatever kind of "case" you're actually modeling. :) Greg

Derick Rethans

19 years ago
On Thu, 8 Mar 2007, Ralph Schindler wrote:
> Stanislav Malyshev wrote: > > > Is it still the position of internals that reserved words cannot be used > > > as method names or class names? > > > > Why allow it? It would probably require substantial change in the parser, > > and what for? > > > > I guess so that we can have a language that will be able to model real world > problems... instead of the real world changing the name of the problem to fit > the language.
You should prefix your classes in the first place, as per: http://www.php.net/manual/en/userlandnaming.php especially point 1 of: http://www.php.net/manual/en/userlandnaming.rules.php regards, Derick

Ralph Schindler

19 years ago
Derick Rethans wrote:
> > You should prefix your classes in the first place, as per: > http://www.php.net/manual/en/userlandnaming.php > especially point 1 of: > http://www.php.net/manual/en/userlandnaming.rules.php >
In the end (After reading the page on smalltalk), I concede. Stanislav makes some excellent points.. and while this is an annoyance, I agree I can (as well as other developers) be a little more creative in class/method naming to not find themselves in an issue with clashing. That being said: I still think there exists validity in figuring out if adding a layer of 'user context' to the tokenizer/parser would be an interesting project. I would be interested to see if a) it could be done, and b) if it could be done with minimal impact on performance.. Which I have to say, is a key reason I have chosen PHP as a devlopment platform. I also think having a context aware parser/tokenizer would segue into namespacing, which I have also heard could be a feature in the future of PHP.. Either way, I am dropping this for now, but perhaps when I can dedicate some time to the 'C frame of mind', I'll start poking around in php-source again. In any case, thanks, -ralph

Marcus Börger

19 years ago
Hello Ralph, unless someone replaces all the parser and lexer code and the tools around we developed this is independly of our position impossibly. As doing so is not possible we don't even have to discuss pros and cons. best regards marcus Thursday, March 8, 2007, 9:48:46 PM, you wrote:
> Is it still the position of internals that reserved words cannot be used > as method names or class names?
> I need this to work
> <?
> class Case > { > /*.... methods and properties ....**/ > }
> but PHP refuses to allow it.
> Please tell me someone is listening. > -ralph
Best regards, Marcus