Eiffel, case insensitive ? is that a bad thing ?
mithen
read somewhere that Eiffel is case insensitive. Is this true
or has it been changed. Please correct me if I am wrong on this.
I am surprised if Eiffel is case insensitive because
it allows programs to alternate the name by which they
refer to the same variable/function/class, which can lead to
unreadable code, or just frustrating to read code.
To me it looks like the Eiffel community is relatively small. Most of
the
people who have an interest in eiffel have an interest in
programming discipline. It is reasonable to believe that
everyone will follow implicit naming conventions.
Of course as eiffel grows larger, goes mainstream, there is nothing to
stop
programmers from using odd naming conventions. In general
I think Eiffel takes the philosophy that:
(correct me if I am wrong here)
Instead of making an implicit rule that we expect programmers to
follow
because they are good programmers, lets force programmers to
do the right thing with an explicit rule. I happen to like that
philosophy.
I see case insensitivity being contrary to that policy. I have noticed
that
in every example I have seen, class names, are all upper case.
If such names are by silent agreement going to be all in upper case
Why not just create a hard rule to force class names to upper case ?
Otherwise You are leaving the door open for trouble.
I am a C/C++ programmer, so I am used to case sensitivity,
I may be biased. However Its not _my_ lack of freedom
that makes me dislike case insensitivity, but the
abusive freedom for another programmer to ignore
spelling/case consistency.
By the way, in such languages that are case insensitive (i.e. basic)
programmers do make spelling inconsistencies (out of laziness).
It does happen, and if the door is left open in Eiffel it will happen.
Comments ? Corrections ?
Thank you
-Pat Mucci
Ken Carpenter
>
> If you want to enforce a certain style, use a style checker.
>
> Or, just run the code through the Eiffel short or flat tools, they
> format the code using the standard style.
>
> What we would absolutely hate is two valid Eiffel features differing
> only by case:
>
> put (i: INTEGER) ...
> Put (i: INTEGER) ...
Agreed, but the compiler could easily detect and disallow
such similar names, while still requiring all uses of the
name to use the exact case.
I find code like the following just as bizarre:
x.Put(a) -- Two calls to the same feature
x.put(b) -- Huh? No error here?
Ken Carpenter
Joachim Durchholz
>
> I read somewhere that Eiffel is case insensitive. Is this true
> or has it been changed.
Yes it is true. The SmallEiffel compiler actually is case-sensitive, but
that's usually considered a bug (and now that it can be switched off via
a command-line option it's a feature :).
> I am surprised if Eiffel is case insensitive because
> it allows programs to alternate the name by which they
> refer to the same variable/function/class, which can lead to
> unreadable code, or just frustrating to read code.
It's even more frustrating to get compiler errors (or even run-time
errors) because of errors in letter case. (Believe me, I'm programming
in C++ for a living, and it *is* frustrating, especially if you work
with libraries that have an inconsistent naming style.)
It is also frustrating if you can't tell somebody the name of a
subroutine over the phone. Letter case just isn't spoken, it is
redundant information that makes reading text easier.
> Instead of making an implicit rule that we expect programmers to
> follow because they are good programmers, lets force programmers to
> do the right thing with an explicit rule. I happen to like that
> philosophy.
Actually the Eiffel philosophy is different: Be picky on things that
matter, and generous on stuff that doesn't really matter.
There's a lot of personal style involved in how the issues were
classified, but letter case really doesn't matter. Adherence to letter
case wasn't considered important (besides, if you really need a
perfectly-formatted class, run it through a prettyprinter, and you'll
get the indentation right along with letter case). Relying on automatic
tools for tedious tasks is very much in line with the Eiffel style; a
similar basic decision was "if we're making the life of the compiler
writer harder but the life of the programmer easier, let's do it".
> If such names are by silent agreement going to be all in upper case
> Why not just create a hard rule to force class names to upper case ?
> Otherwise You are leaving the door open for trouble.
No. A class name cannot appear where a variable name is, and vice versa.
A declaration of the form
integer: INTEGER
is valid (though silly), and it still says the same if you're writing
INTEGER: integer
or
Integer: INTEGER
> I am a C/C++ programmer, so I am used to case sensitivity,
> I may be biased. However Its not _my_ lack of freedom
> that makes me dislike case insensitivity, but the
> abusive freedom for another programmer to ignore
> spelling/case consistency.
Well, just run it through the prettyprinter.
If you don't like the prettyprinter: Just assume it's the same kind of
discipline that you need to get the indentation right.
> By the way, in such languages that are case insensitive (i.e. basic)
> programmers do make spelling inconsistencies (out of laziness).
Now the problem in Basic is that a misspelled name will implicitly
declare it. No such trouble can occur in Eiffel, as everything must be
declared somewhere (just as in C++).
Regards,
Joachim
--
Please don't send unsolicited ads.
Loryn Jenkins
Or, just run the code through the Eiffel short or flat tools, they
format the code using the standard style.
What we would absolutely hate is two valid Eiffel features differing
only by case:
put (i: INTEGER) ...
Put (i: INTEGER) ...
Loryn Jenkins
Loryn Jenkins
> such similar names, while still requiring all uses of the
> name to use the exact case.
Then you should enjoy using SmallEiffel, with case sensitivity turned
on.
Loryn Jenkins
Reimer Behrends
[...]
> I am surprised if Eiffel is case insensitive because
> it allows programs to alternate the name by which they
> refer to the same variable/function/class, which can lead to
> unreadable code, or just frustrating to read code.
IMO, It is actually the lesser evil. With languages that are case
sensitive you sometimes have the unhappy situation that there are
different identifiers that only differ with respect to their
capitalization. So you've got someFoo as well as somefoo, and they are
actually different.
It might appear to be the best of both worlds to actually enforce
consistent spelling for each identifier, but then you run into problems
when style guidelines enforce a change in capitalization (like in
Eiffel, where once routines and constants start with a capital letter,
and normal routines do not -- redefine one to be the other, and such a
strict policy would give you nothing but trouble).
[...]
> I think Eiffel takes the philosophy that:
> (correct me if I am wrong here)
>
> Instead of making an implicit rule that we expect programmers to
> follow
> because they are good programmers, lets force programmers to
> do the right thing with an explicit rule. I happen to like that
> philosophy.
I don't think that this is Eiffel's philosophy at all. Rather, Meyer
says that you just can't prevent bad programmers from writing bad code;
instead, you should focus on giving good programmers the tools to write
good code. So Eiffel gives you lots of support in matters that prevent
you from shooting yourself in the foot, but if you absolutely want to
point the gun at yourself, it supposes that you know what you are doing.
(If I am paraphrasing incorrectly from ETL, somebody please correct me.)
And I have to agree with this. I had the misfortune of having to
maintain some really bad code written by others. No language feature
could have prevented the conceptual spaghetti I had to deal with, and,
frankly, if inconsistent capitalization had been the worst of my
worries, I would have been exultantly happy.
You can deal with inconsistent capitalization automatically (I think it
would take less than an hour to write a Python script to fix
capitalization). You cannot automatically deal with inconsistent
design.
[...]
> By the way, in such languages that are case insensitive (i.e. basic)
> programmers do make spelling inconsistencies (out of laziness).
> It does happen, and if the door is left open in Eiffel it will happen.
Well, it does not, at least not in my experience. I think this is part
of the language culture. In any event, as I pointed out before, it is
the lesser evil, compared to permitting superficially similar
identifiers with different meanings.
[...]
Reimer Behrends
Reimer Behrends
[...]
> I find code like the following just as bizarre:
>
> x.Put(a) -- Two calls to the same feature
> x.put(b) -- Huh? No error here?
Remember that you may be dealing with once routines (first letter
capitalized) vs. normal routines (all lower case) in a polymorphic
language.
Still, I agree that I'd appreciate to get at least a warning.
Reimer Behrends
Joachim Durchholz
>
> I find code like the following just as bizarre:
>
> x.Put(a) -- Two calls to the same feature
> x.put(b) -- Huh? No error here?
This is just a question of getting used to it. I had some long-term
exposure to Pascal, and I found such inconsistencies just mildly
irritating. What made be really furious was wrong indentation.
Andreas Leitner
> Remember that you may be dealing with once routines (first letter
> capitalized) vs. normal routines (all lower case) in a polymorphic
> language.
>
> Still, I agree that I'd appreciate to get at least a warning.
>
> Reimer Behrends
Well, but that brings back good ol´ warning vs. error debate. I think on
the one hand you can run a pretty printer over the source from time to
time. For warnings on the other hand, I have no real arguments against,
but my instinct says no.
For example SmallEiffel has warnings, but if you are going to use the
gobo library (which is IMO a very good library) you need to turn
warnings of, because SmallEiffel will flood you with warnings otherwise.
You won´t benefit from any kind of warnings in this case.
best regards, Andreas
Graham Perkins
> ..
> I am surprised if Eiffel is case insensitive because
> it allows programs to alternate the name by which they
> refer to the same variable/function/class, which can lead to
> unreadable code, or just frustrating to read code.
From my point of view as a teacher, case insensitivity is by
far the better choice for a language. Modula-2, Java, Smalltalk,
and C(++) just get us bogged down in a way that never happens with
Pascal, Eiffel, Cobol.
Now as a guess, I'd say that things that are problematic for
undergraduates with 1-3 years programming experience are also
going to be problematic for professionals, even if they are
better at coping.
Also I think you'll find most command languages, macro languages
and 4GLs are case insensitive. Also file and device naming.
And in the real world British Airways and BRITISH AIRWAYS are
the same airline.
-------
Please don't suggest that you could easily fix the compiler
to warn about similar names that differ in case only. Make
your mind up one way or another. You must know by now how
most programmers deal with cascades of non-fatal warnings!
----------------------------------------------------------------
Graham Perkins, De Montfort University, Milton Keynes
http://www.mk.dmu.ac.uk/~gperkins/
Ian Joyner
> Hello, I am new to Eiffel and making my way through things. I
> read somewhere that Eiffel is case insensitive. Is this true
> or has it been changed. Please correct me if I am wrong on this.
>
> I am surprised if Eiffel is case insensitive because
> it allows programs to alternate the name by which they
> refer to the same variable/function/class, which can lead to
> unreadable code, or just frustrating to read code.
I'm not quite sure of your meaning here, perhaps an example would clear it
up. But this seems to be the argument for rejecting case sensitivity. Being
able to have entities named Fred, fred and fRed is confusing. I would
rather avoid such tricks. C case sensitivity dates back to the fact that
they did not want to waste memory and processor cycles. However, being
limited by the technology of the time has led to all sorts of spuious
arguments of why it might be correct.
--
Ian Joyner
Microsoft Research Institute Macquarie University
i.jo...@acm.org
http://www.mri.mq.edu.au/people/ian.html
Reimer Behrends
[...]
> For example SmallEiffel has warnings, but if you are going to use the
> gobo library (which is IMO a very good library) you need to turn
> warnings of, because SmallEiffel will flood you with warnings otherwise.
> You won´t benefit from any kind of warnings in this case.
I should have been more precise. What I would like to have is some way
to clean up inconsistencies with respect to capitalizations. One such
way would be to have the compiler tell me about them if I ask it to
(such a warning should of course not be enabled by default).
Reimer Behrends
Henry Takeuchi
: Agreed, but the compiler could easily detect and disallow
: such similar names, while still requiring all uses of the
: name to use the exact case.
: I find code like the following just as bizarre:
: x.Put(a) -- Two calls to the same feature
: x.put(b) -- Huh? No error here?
Why make the programmer do that?
An IDE could do the work, too.
As an example, Visual Basic (also case-insensitive) enforces syntax style.
(One of the few concessions to programmers is indentation.)
It capitalizes keywords and each programmer-defined identifier is
displayed with the exact same mix of case. So if you type RecordCounter,
that's how it shows up everywhere (VB uses the last version typed in).
And even if you don't use an IDE, the compiler could produce a listing
(anybody remember them?) with an editted version. Or you could use a
"beautifier" or "prettyprinter".
--
Henry S. Takeuchi
ht...@eskimo.com
Seattle, Washington (USA)
David Clark
example from a submission to the Australian Informatics Olympiad
competition which one of the organisers had to sort out.
It speaks for itself.
"The mailer changed
IF ... THEN ... : EXIT SUB
into
IF ... THEN ... :
EXIT SUB
which, although legal means something quite different."
David
David Clark
University of Canberra
dav...@ise.canberra.edu.au
Joachim Durchholz <joachim....@munich.netsurf.de> wrote in article
<3617C0CE...@munich.netsurf.de>...
mithen
You could require that the casewise spelling of the
first invocation of an identifier be consistent throughout
a project.
So the answer needant be a polar 'case sensitive' versus
'case insensitive' leaning. Personally I like my solution :)
-P Mucci
Ian Joyner
> Ian Joyner wrote:
> >
>
> > I'm not quite sure of your meaning here, perhaps an example would clear it
> > up. But this seems to be the argument for rejecting case sensitivity. Being
> > able to have entities named Fred, fred and fRed is confusing. I would
> > rather avoid such tricks. C case sensitivity dates back to the fact that
> > they did not want to waste memory and processor cycles. However, being
> > limited by the technology of the time has led to all sorts of spuious
> > arguments of why it might be correct.
>
> You could require that the casewise spelling of the
> first invocation of an identifier be consistent throughout
> a project.
>
> So the answer needant be a polar 'case sensitive' versus
> 'case insensitive' leaning. Personally I like my solution :)
I agree, and although I like the idea of using consistent case in all
occurrences, in many cases, this would be too picky. Perhaps a compiler option to
enable it would be best.