Name Implies Type

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