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

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

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).

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 ”

The only disclaimer I would add, is that I would not name a type using
a plural. This may seems natural at the type definition, but this will
be less natural at object instantiations (unless the type is a
containers, and the containers is named after the concrete type of
items it contains).

> 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).


Thanks for having notice (I mean, thanks for the correction)