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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sat, 31 Oct 2009 05:38:32 -0700 (PDT), Hibou57 (Yannick Duchêne) wrote:

> On 31 oct, 12:47, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Sat, 31 Oct 2009 04:30:38 -0700 (PDT), Hibou57 (Yannick Duchêne) wrote:
>>> On 31 oct, 10:49, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>>> wrote:
>>>> "the cats"
>>> This is a class, not a type
>>> So let's call classes The_Xxxs (with an ending S)
>>> But what about types ? (and instances of a type)
>>
>> Class is a set of types. Type is a set of values. When the cat is an
>> object, the cats is its type. Mammals is the set of types that contain the
>> type cats. The corresponding type can be the mammals, i.e. flatten mammals
>> class.

> You are right, this is not a class.
> But the type may rather be seen as an abstraction of each individual
> instance (or as a representation of all the possible instances, thus
> the set, but not as a set of instances). The type, provide the way to
> create an instance, it may be used to create a set of value, but it is
> not a set of value (I know you use type right, I'm just trying to make
> terms clear).

Well, the set of all values of a type is equivalent to the type itself. It
would make little sense to distinguish them. That is formally. Practically
there is an aspect of constructiveness. We cannot enumerate all integers,
so we name them as Integer in order refer the set of, without constructing
it in the body. Any set of values is a type but it is incomputable to
decide of which type. In other words since structural equivalence does not
work we need type names. And even if the type T is "new Integer", indeed an
integer, we do not recognize that, and treat T and Integer distinct types.
That is another reason why we are short in type names.

> So let say now your « The Cats » is a type, and finally there is
> something which mark it, so this goes in the way of a mark to state a
> name is used a a type. “ The ” and the plural, may be seen as
> equivalent to the “ _Type ”

This is the instance-to-set way, but there is reverse approach:
set-to-instance. E.g. "of x", the possessive case "x's", the article "a x".
Natural languages are damn flexible.

Some people like:

   procedure Skin (Cat : A_Cat);

others do

   procedure Skin (A_Cat : Cat);

(:-))

I don't like either. Sometimes I do:

   procedure Skin (Victim : Cat);

Many do

   procedure Skin (Object : Cat);

Some natural languages apply cases to indicate objects:

   procedure Skin (Objet : Cat; Tool : Knife; Customer : Butcher);

(accusative, instrumental, dative cases). Interestingly that cases
represent some kind of types (roles) of objects.

>> In Ada there is no notation for the class. T'Class is a type, the closure
>> of the class rooted in T, i.e. all values of the members of types derived
>> from T.

> This do the job, isn't it ? And this is true that a type — which may
> be, at least potentially — the subject of any number of derivations,
> at least potentially stands for a class, even it is not actually
> derived. So there is no trouble to get the class rooted at a type from
> a type attribute. There is no need for an explicit declaration of a
> class, because the class associated to a tagged type, always exist,
> that's the concept, and does not need any declaration (the subtype is
> there, if a declaration is needed or wished).

No, it is rather because T in T'Class is decidable. But it is not
necessarily always so. Already with generics people run straight into
troubles passing T'Class for a plain formal type and wondering why no
dispatch happen. Again the question is how and if "member of" is
computable/obvious. Once types might become a more first-class citizens, or
the structure of classes more complicated T'Class might cease to work well.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de