[ Attn: Randy ] "Selective" Case Neutrality in HLA??

From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 10/26/03 

Date: Sun, 26 Oct 2003 12:32:36 -0000

Hi Randy,

    Yes, I know case neutrality is a good idea, especially for
teaching beginners and all that sort of thing...but couldn't some sort
of option be added to specify what to use?

The essential problem is that, whilst HLA is very good to use case
neutrality on identifiers, other programming languages aren't...C /
C++ most notably...and there's, worse still, a convention floating
around to put data types in CAPITALS (perhaps_with_underscores) and
instances of datatypes in lowercase or MixedCase...

And though HLA can get by on its own without this sort of thing and
does well because of it, it's a pain to do things like properly
convert some C / C++ header files...and, well, for most things of
interest - like libraries and so forth - C / C++ header files are what
you have to convert from, as it tends to be the "de facto" standard
for this sort of thing...the Windows datatypes ("HWND", "HINSTANCE",
etc.) are a classic example - which you've already met, I'm sure - but
there are others which could crop up too (some other C-based library
taking a similar naming strategy...as, unfortunately, as nasty as the
Windows scheme is, it is based on that "Hungarian" convention and
other libraries may also elect to follow the same scheme)...though you
can often substitute a simple "DWORD" for some of those kinds of
things, you have to question "what's the point of a data typing
system, if we're just going to ignore / abandon it upon meeting the
first UPPERCASE identifier in the file (which is, of course, an
unrelated thing to data typing so giving it up just because of badly
chosen C / C++ identifiers is a bit weird, surely)?"...

Now, I was thinking that the best overall solution is that
"namespaces" (including the "global" namespace...although, not sure
how you'd get access to it, another than a new keyword or define or
something...this would be a rare option, anyway, to switch to case
sensitive throughout...only thinking of this option for some C / C++
coder who really, really insists on such identifier names...you know
what people are like, after all, "there's always one", right? ;) are
"case neutral" by default (because that is a great idea) but that you
could specify something like: "namespace Example; @casesensitive;" or
something and then identifiers inside that namespace can be forced to
be "case insensitive" (PASCAL and BASIC people happy there :), "case
sensitive" or "case neutral"...where case neutral is the _default_ if
nothing is specified, so if you don't make use of these options then
HLA still operates as it's always done...but for something like a
"Windows" namespace or whatever - where you'd like to keep as close as
possible to the standard C / C++ identifiers (the whole documentation
issue that many libraries - not just Windows - are C libraries, follow
C naming conventions and all the documentation about them is written
with C / C++ in mind) - you could put "@casesensitive" on the
namespace and, hey presto, all the "proper" C / C++ identifiers
(except for the one or two unfortunate things like "cx" and "to",
which are unavoidable conflicts, save for changing HLA's syntax
totally or something silly like that...anyway, where Windows uses
"cx", the name "width" tends to be infinitely better and more
descriptive you have to wonder what sort of drugs they were taking
that possessed them to choose such a weird name ;) so that what HLA
users use is exactly like the C / C++ documentation and other articles
in 90% of cases (and, of course, the closer it is, the more you are
encouraging the easy transition of the immense wealth of C / C++
material out there to be converted over to HLA, making the idea of HLA
as a "C substitute for coders concern with low-level coding and
output" a possibility...strides in this direction should be taken
because, quite frankly, if HLA could be put properly in between ASM
and C then that would mean I could even give up the typical ASM / C
mix programs for a single tool :)...Windows is the most obvious
example where bad naming choice has kicked out proper data typing
because there's "hwnd" and "HWND" in many places...but the same
overall principle is applicable to many other libraries that might
need conversion from a case sensitive / insensitive language to HLA...

Plus, anyway, MASM allows case sensitivity to be changed and you
wouldn't want to be accused of having a worse macro system than MASM
(sorry, but if rationality fails, then emotional blackmail over your
"ego" might persuade you instead...well, okay, might not work in your
case but it would work brilliantly for most ego-loaded coders out
there...hehehe ;)? But, like I say, if what you do is attach the
sensitivity options to _namespaces_ then you get one of those "best of
both worlds" options...the beginner HLA coder's program _is_ case
neutral, it's just that Windows isn't so just that namespace is made
case sensitive (and because each namespace is separate then there
shouldn't be the slightest conflict in doing this sort of thing at all
:)...then the data typing system isn't compromised simply because of
bad identifier names...I mean, that is a little silly...granted, data
typing isn't so important with ASM coders in general...but if it
exists in HLA, it seems daft to go to all the effort of adding it,
only to immediately bypass it by declaring everything as "DWORD",
anyway...for instance, it would be great to type cast all of the
"@returns" to the correct data type...even if only purely for
documentation reasons that looking at the prototype tells you what's
returned...something like "@returns("(type win.BOOL eax)");" or
whatever..."case" and "typing" are separate issues and one shouldn't
be really compromising the other, even if, granted, it's only doing
that because of unthinking C programmers using bad naming ideas...it
still shouldn't be a case of one interfering with the other
independent issue...

Further, people who do Windows programming with MASM32 may be used to
"DWORD for everything" but if you're used to doing most of your
Windows programming with C / C++ using the standard header files then
it's actually a really hard habit to get out of typing "HWND" and
"UINT" and so forth...I mean, we all know that these are just "DWORDs"
so it's not really "behind the scenes"...it's a _logical_ rather than
physical thing...yes, they are all "DWORDs" but this particular DWORD
is a "handle to a window" so it doesn't get passed as a "pointer to a
unicode string" and all that sort of thing...it's the essence of data
typing that you're trying to forbid _logical_ incompatibility, not any
physical size incompatibility (plus, if you were serious about "don't
be a hacker" then you should be setting the good example...also, I'd
say that data typing doesn't get in the way hardly ever when you're
actually going with it rather than fighting it...and if you're trying
to fight it all the time then this sounds like a symptom of being a
"hacker" ;)...if you've got a typing system then it seems daft not to
use it...especially because HLA always has the ability to allow you to
declare "DWORD" and then the system is effectively switched off (save
for "size checks" - which, contrary to popular opinion, actually _is_
a form of type checking, just an incredibly loose one - that most
assemblers have anyway :)...

Also, a bit like the "@fast" option, there's an essential difference
between just reaching into some already defined namespace to find a
library function or whatever, than for actually creating one
yourself...if you're making a new one then, yeah, it's a very good
idea and practice to do the whole "case neutral" thing...but for
namespaces that are just "mirrors" of C / C++ or Pascal header files
or something then you're not making these up, you're having to use
what's defined in those files...

Although, I'm thinking this might be a pain the arse to do, perhaps?
Don't know exactly as I haven't looked at the HLA source code in
detail to see how it implements this stuff...couldn't an extra
"sensitivity" option be added onto namespaces (to go with the "@fast"
option) and then the look-up is / isn't / is partially case sensitive?
And, doing it as a "per namespace" thing is a way to keep case
neutrality as the default behaviour and not break any existing stuff
but to add it for those occasions where some unthinking C / C++
programmer has tapped in those horrible UPPERCASE identifiers
everywhere...because, as you yourself have noticed I read from the
documentation, you've realised that keeping to the "standard" names is
an awful lot more useful and practical than trying to rename them to
something more sensible...sometimes you don't have a choice (clashes
with a reserved word) but it should be minimised as far as possible...

So, Randy, any chance of seeing such "case options" added to HLA?
Perhaps as a v2.x thing rather than now or whatever...but consider
this a formal complaint and suggestion because it has been an
unnecessarily annoying thing...and workarounds and hacks are ugly and
NOT good "software engineering" (like you could probably work out some
macros that do text substitution, perhaps, to get around this, albeit
in a "global" rather than "selective" manner)...case neutrality _is_ a
great idea and should be left alone as the "default" for beginners and
stuff...but there are "advanced" uses - creating header files for
defining C / C++ based library interfaces - where it just gets in the
way...thus, all round, being able to _selectively_ choose how each
namespace is treated would, I think, solve the issue in a satisfactory
manner for all concern (and namespaces are all separate, by
definition, so this should not cause any "conflicts" or anything
either :)...and it can be one more "unique" feature to sell HLA
on...as is slightly typical of any idea that comes out of my brain,
"selective case sensitivity" is something you'd be hard pressed to
find elsewhere...but it should do the trick admirably...

Beth :)

Quantcast