Re: case insensitive tokens??

["Etienne Gagnon" <egagnon@sprynet.com>]

Bob and David,

We live in a free world, where everyone has the right to express his
opinions. Let's just make sure that we don't make personnal attacks while
expressing them. Both of you are right assuming your own views of software
engineering.

It is normal that we may disagree on design issues. The proponents of two
very popular languages, C++ and Java, have very strong and divergent
opinions on OO and software engineering in general. This doesn't mean that
one group is right and the other wrong. They simply have two different
approaches.

>...the use of 'private' to 'protect' clients
>of a class is more than a bit controversial in the Software Engineering
>field.

Exactly. Being controversial, some people have one opinion and others a
different one.

Here, Bob and I disagree. Which is OK as long as we respect one's another
opinion. We don't have to agree; I can design SableCC as I wish, and Bob can
modify it as he wishes.

> In my opinion he did not go far enough.

The customization of getChar() requires a very good undertanding the the
innerworking the the Lexer class, which goes beyond the abstraction that
should be provided by encapsulation of functionality in a class (in my
opinion;-).

I am "pretty sure" that Bob's implementation was buggy prior to my warning
on pushback(). In case this was true, it would prove my point that opening
getChar() to customization would be a breach of encapsulation.

But again, this is not hard science. So let's not make a war on this;-)

>
>That's all. Can't do that if getChar is private. If I didn't have the
>ability to change the source of SableCC, with which Etienne has so
>graciously provided us, I would have been wasting my time using SableCC.


You could use the trick I told you of defining case insensitive helpers.
Writing helpers for 24 letters is not long. It has the added advantage of
allowing the use of case sensitive AND case insensitive tokens in the same
state, which is not possible with your approach.

Also, the efficiency fo getChar method is quite central to the efficiency of
the lexer in general. Adding a comparison on each call might be expensive.
Using helpers should be more efficient. I'll let you do the comparisons...

So, I am not sure that you would have lost your time...

>Since then I've become much "fancier", and have adjusted things so the
>character is shifted only for comparison against the tables leaving the
>original unshifted text in the token. But not even this is real hacking,
>thank you, even though this kind of activity is potentially dangerous.


The potential dangers of such an approach is what kept me from opening the
intenals of the Lexer class to customization. The goal of SableCC is to let
you do as much as you want while, at the same time, keeping you from hurting
yourself. This is in the trend of Java's philosophy.

The C and C++ philosophy is to warn you that you might be shooting yourslef
in the foot, but to let you do it if you want to. I did not wish to take
this approach (personal preference).

>I had a decision to make: toss SableCC or make it more customisable.


Or to use my trick, if you wanted... ;-)

Anyway, at this point, everyone should be happy. Normal users of SableCC
have a "safe" environment to play with, and Bob has his customized
environment that lets him do his job efficiently. No body was harmed.

So, let's try to keep this harmony:-)))

Etienne