Re: Types, packages & objects : the good old naming conventions question (without religious ware)

["Hibou57 (Yannick Duchêne)" <yannick_duchene@yahoo.fr>]

A quick add-on, before I forget to write it back here - comments
welcome on the assertion :

A program language terms use the dictionary of natural language.
The natural language has some construct like predicates, adjectives,
verbs (transitive and intransitives ones), an nouns.

some has one to one match with the concepts used in a program text :
predicates and adjectives, verbs (of both forms).

Remain nouns : they may match either object of types, just because the
natural language does not make this distinction. Indeed, in every day
life, we are not talking using type and class concepts (neither our
ancestors does).

Human being understanding of things, which is reflected in the nature
of the language it use (the Human being), because it creates the
language to serve to purpose of transmitting its minds, prefer to use
stereotypes : it take a typical example, which is a *real* instance,
and defines other instances after that typical real instance.

Thus, the word « cat », which may either refer to Douda, my pet cat,
or to all Cat being (if I can say it this way).

So, it may be seen as un non-formal proof that the vocabulary and word
derivation construct from natural languages, does not provide anything
to make a clear distinction between an instance and the abstraction of
any-instance-of, simply because any instance, may be subject to become
a typical representation of an abstraction as soon as it is notices
that it has finally some property which makes it different from others
and that these properties are shared by some other. Ex. my Pet Cat,
she like to beat just to play. There are others which do the same. At
first sight, she is well represented by the typical representation of
a cat, which is some cat (any one), but later, when you know her, you
use this reference to her in another way.

So, in the natural way of Human being understanding process, there is
no distinction at all, between an object and a type or a class,
because an object may become a type or a class at any time.

Finally, the natural language the Human being has created fulfill the
needs of this process, providing a set of words which can serve this
purpose, that, words which means things which may be either object or
types, without this distinction being made.

Here comes the clash between object name and type name. Perhaps this
is not a matter of weither or not some one did not choose the good
word from the natural language, and more a matter of that the natural
language does not provide good words for that purpose : a word which
may match the expression of what a type is, may be found, but with two
things important to note : this word will never express it is a type
(for the reason expressed before) and this word will *necessarily* be
the word which should be used as well to name an object (still for the
reason introduced before).

At this point, there is three possible way to do things (if you think
about others, just add your own and tell about) :

1) Created fully new words dedicated to type, not coming from the
natural language, as the natural language does not provide any.
2) Formally split - in a developers wide standardized way - the whole
set of words from the natural language in two separate and non-mixable
set : one set for restricted to objects name, one set restricted for
type names.
3) Add a derivation (which is a known construct of the natural
language), to mark some property on some words, just like the already
given example of plural does with the “s”. This may be done it self in
three possible way : create a mark for types, meaning “ I'm a type
” (object will be the ones without this mark), or create a mark for
objects, meaning “ I'm an object ” (types will be the ones without
this mark), or create a mark for both type and object, meaning “ I'm a
type ” for the first one and “ I'm an object ” for the second one.

Comments on these methods (if you think about others, add you own as
well).

About 1) : this would not be practicable... the set of words from the
natural language taken long to be created, and Human being capacity to
learn such a things is not unlimited (this would be nice for a machine
to create and use such a create-from-the-ground-up language, but we
are Human beings, not machines).

About 2) : such a standard would take long, long, long, with infinite
elections before being stable. And further more, we may discover that
one objet-type (as with natural language its always the two things at
the time) may only have a single word to refer to, and no synonym at
all. Then, even providing we may be able to standardize such a split,
we may end up with some object without word (or type without word), as
we will have to decide if we assign this unique word to either the
type names set or object names set. Then and even if it would be less
work to learn it (less than with the proposition #1), this would still
be a lot of work for every one to learn it, ... and be sure there will
be confusion, because we will have two set of words, whose words from
one set will be synonyms of the words from the other set (synonym in
the natural language way, but not in the program text way).

About 3) : there are in turn three way to do it.

About 3.1 (a mark for types) : a lot of people already know it, so no
need to explain.
About 3.2 (a mark for object) : it seems it has been in use in some
old methodologies (I do not know names, sorry), I used it my self in
some old Pascal programs.
About 3.3 (a mark for both) : just combine de two previous

Some along fact about 3) :
- We spend more time to read than we spend time to write.
- We write more object names than we write type names (indeed, there
more instance than there instance abstraction, except in libraries).

This may be a suggestion to have shorter names for object (quicker to
read and to write) than for types, thus this may be a suggestion to
drop 3.3 and 3.2, leaving just 3.1

Remains a thing which after all this formalizations, will remain a
matter of taste : the choice of the mark on the type (suffix, prefix,
casing - not for ada - and anything else, things which already in use
in some conventions).

Is this mark very important to be standardized ? Perhaps not, as soon
as it clearly appears to stand for types, it is clearly distinct
(should not be erroneously seen as the part of a word - the Ada
underscore may help there) and easy to write and read (just avoid
exotic characters or marks, even if some may be tempted in some
mathematic of linguistic dedicated character sets).

Time for comments now


Note : if a language makes more use of types than objects, objects
should have the mark instead of types, that's obvious, while better
said explicitly.