On 21 May 2010 20:35, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> Hi Igor,
>     I think you're misunderstanding what xUnderscoreForTokenization is for.
>  One important use case is opening a ChangeList on a source file containing
> assignment tokens which are different from your preferences.  If one
> uses xUnderscore one will not be able to parse the file correctly as it will
> raise errors via calling xIllegal.  xUnderscoreForTokenization however will
> not cause an error and will simply create a token, be it from '_' or ':=',
> allowing one to parse the file and therefore see it contains different
> assignment symbols rather than having to infer from the flurry of errors.
> So please, do not remove xUnderscoreForTokenization.  Its useful.  I use it
> in places where I definitely do not want an error to be raised where
> non-preferred assignment symbols could occur.  It is not used when compiling
> source.
> best
> Eliot

I know. And i don't removed it.
But i wanna solve the problem with source code verification,
which called from CodeHolder, when its contents changes.
It using  parser's #parseSelector: and #parseParameterNames:
which in own turn calls #initScannerForTokenization

Then it shows a warning for every method, which contains underscores
in selector,
without taking into account that
a) underscores is enabled globally via preferences
b) underscores is enabled locally for a class, which contains the
method you viewing

I changed these two methods to not use #initScannerForTokenization ,
so they are honoring the
global preference.
But to honour (b), these methods need to also take a class as parameter, i.e.:

parseSelector: aString inClass: aClass
parseParameterNames: aString inClass: aClass

Or.. instead of changing a parser, we could change the
CodeHolder>>validateMessageSource: sourceString forSelector: aSelector

to honour both (a) and (b) in some different way, that won't require
changing a parser.

>
> On Thu, May 20, 2010 at 11:18 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>>
>> Hello,
>>
>> it looks like xUnderscoreForTokenization is now redundant,
>> because xUnderscore does the right thing, depending on preferences you
>> set,
>> while xUnderscoreForTokenization don't using a preferences and that's
>> why you'll get a warnings
>> when browsing a methods which having underscore in selectors.
>>
>> A proposed fix is to make
>> Scanner>>initScannerForTokenization be a no-op.
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.