> Hungarian notation is any of a variety of standards for organizing
> a computer program by selecting a schema for naming your variables
> so that their type is readily available to someone familiar with
> the notation.
I used to request hungarian notation from programmers who worked for me,
until I saw the actual compliance with that request culminate in a local
variable named l_st_uliI. Of course, that's an "static unsigned int i" used
as a simple iterator in local scope. Of course, written more appropriately,
this would have just been "static unsigned int i". At that point, Hungarian
notation fell apart for me. Its strict use adds (IMO) as much confusion as
MicroSoft's redefinition of C, with thousands of typedefs representing basic
types ("LPSTR" and "HWND" come to mind as the most common).
> Just as Python is a language that enforces the common practice of
> sane indentation by making it part of the language, Perl is a
> language that enforces a dialect of hungarian notation by making
> its variable decorations an intrinsic part of the language.
False analogy, bad example, and semantic foofoo. Python's indentation is a
burden to me. It defies flexibility and places a requirement on verbosity.
The only more annoying language I know of in terms of strict structure is
VB, which places my neat colmnar comments in irregular endings at the end of
a line (can't line anything up). Readability, to me, is the ability to MAKE
it readable, not an arbitrary rule to provide (a pretense of) readability by
forcing me to put my squiggly where I don't want it to go. As for the
Hungarian thing, Perl's $%@& is a far cry from it, though I have seen
$strSomething in new programmers.
> What if, instead of cramming everything into "scalar" to the point
> where it loses its value as "a data type that magically converts
> between numeric and string, as needed," we undo the Great Perl5
> Dilution and undecorate references.
This is frightening me too. I really don't like the thought of
$i = "1.0";
$i += 0.1 if $INC;
$i .= " Foo, Inc.";
(or more specifically a one line version that converts several times for a
single statement)
becoming
my str $i = "1.0";
if($INC) {
$i.asFloat += 0.1;
}
$i.asString .= " Foo, Inc.";
We appear to be moving in that direction, trading programmer convenience
with politically correct verbosity.
> my dog $spot; #spot is a dog that looks like a scalar
> #spot holds neither numeric nor string data
> #why is spot burdened with the BASIC
> #string identifier?
$ isn't BASIC. (Actually, ancient BASIC was var$ rather than $var.) It's a
remnant from other UNIX utilities such that
set this = "that";
print $this;
% and @ also have historical context that makes sense.
> So what I am suggesting is, Scalar as catch-all for unclassifiables
> that are neither strings nor numbers may have been a historic stopgap
> measure in perl 5 which was seen to be unworkable given the profusion of
> object types which became available in perl 6.
As long as it roughly resembles the Perl language.
