Am 19.11.2005 um 14:09 schrieb stéphane ducasse:

> On 19 nov. 05, at 11:58, Bert Freudenberg wrote:
>
>> When dealing with low_level_code, I'd love to have underscores in  
>> identifiers - not even just method names, but for variables, too.
>
> Gloops. I'm not sure I would like to have that. :)
> Because when I see foo_bar in the code I have to know that this is  
> a variable and not foo _ bar.

Well, I certainly hope never to see _ as assignment anymore.  
Either := or ← should denote assignment.

> I have the impression that we have lot of work in other places to  
> let this one stable :)

Indeed :)

>> This could probably be achieved simply by using a different type  
>> table with $_ being an #xLetter in Scanner (not sure about the  
>> SmaCC-based Compiler).
>>
>
> Not sure.
>
>
>> However, I would also strongly suggest *not* to allow this as a  
>> standard. Apart from breaking old code file-ins, we would soon get  
>> tons of unreadable gibberish by C-trained newbies ;-)
>>
>
> This is why I would love to remove caseOf: too :)
>
>> Instead, when filing in, the compiler would interpret underscores  
>> as assignment, just as it is now. *Only* if specifically enabled  
>> by the filed-in code would it be switched to allow underscores in  
>> identifiers. Same goes for normal development - *unless* a class  
>> answer true when asked #allowUnderscoresInIdentifiers, underscores  
>> are compiled as assignments. The file-out code would take that  
>> into account to generate the code snippet enabling underscores in  
>> identifiers needed for later file-in.
>>
>> How does that sound?
>>
>
> I thought that we could assign a compiler class to a class. At  
> least in VW this was that way that roel
> loaded Prolog like methods with a file in.

Sure - this is what everybody can do right now.

> So I would avoid the preferences plague. But make sure that the  
> superclass returned a specific compiler
> and may be fix that changing the compiler of a class is working if  
> it is not currently.

I wasn't talking about a global preference, but about something as  
local as possible, like enabling it for a certain class.

- Bert -