In some programming languages, the type of an object is encoded into its name somehow. (This does not refer to
HungarianNotation, which is a naming convention not enforced by the language definition). Examples:
- In BasicLanguage, strings have $ at the end of their name.
- PerlLanguage allows a name to refer to multiple objects, such as scalars, arrays and hashes, all within the same scope. The exact meaning of any particular usage is determined by the surrounding syntax, often disambiguated by prefix characters. This is orthogonal to perl's type system that encodes and coerces int, float and string dynamically.
Most languages don't have this "feature".
Personally, I don't like it; but there are things that rankle me far worse. --
ScottJohnson
In my view, there is
world of difference between a
syntactic implication, as in
PerlLanguage or Fortran, and a
semantic implication, as in
SmalltalkLanguage. To be concrete:
Good: foobarArray
Terrible: @foobar
You're not being particularly "concrete" at all. What is the difference between these? They both say two things: 1) it's an array; 2) it's called foobar. What is "syntactic" about the Perl version?
The Perl version is syntactic in that the '@' symbol is meaningful within the language; it's part of the abstract syntax tree. The 'foobarArray' is just a variable namep; nothing in that name is special unless you're a human reading the code.
I'm of two minds on this one. Things like foobarArray constitute meaningless documentation, and things like '@foobar' provide an unnecessary binding between object properties and name. I'm against the idea of
naming as more than programmer convenience. Ascription is better; (foobar :: Array) and (<value or object descriptor> :: Array) mean the exact same thing - no binding to name, no meaningless documentation.
Compare:
NameImpliesScope
See
SymbolDecorators,
TheProblemWithSigils