Re: Built-in types (was Re: How can I avoid Using a Semaphore?

["Mark Lundquist" <mark@rational.com>]

Ray Blaak <blaak@infomatch.com> wrote in message
news:m33deaaeks.fsf@ns40.infomatch.bc.ca...
> "Mark Lundquist" <mark@rational.com> writes:
> >
> > First I would have to figure out how to think up type names that are not
so
> > cheesy as "My_Int" :-)  And the names shouldn't "encode" specifics about
> > their implementation properties, e.g. "Int16"
>
> Well, you try to have a name that indicates what it is to be used for,
about,
> etc. e.g,
>
>   type Instance_Count is new Natural;
>
> Such names should be independent of the specifics of the type itself.
>
> Note that you would also have the very important benefit of not
accidentially
> mixing up various different "whatever" integers.

Hi Ray,

What we're debating is what to do after all the reasonable scalar
abstraction is done, if indeed there is anything left at that point.  It's
felt by many that it is a mistake to create a new type for every last thing
under the sun (a mistake characteristic of the "wild-eyed proselyte" stage,
it goes along with making everything a task :-))  Dewar asked for a
counterexample, and the one I gave was of an STL-style collection insert
operation that creates multiple copies of a value.  This is just the kind of
situation where creating a new type as you describe above is exactly what
you don't want to do, because it adds absolutely no benefit whatsoever --
the only effect is to force a lot of explicit conversions.  What you want is
the "whatever integer", and I think Integer is fine for this because that is
the meaning of Integer, while Dewar thinks I should define the "whatever
integer" type explicitly.  But Dewar's way does not result in gratuitous
explicit conversions, because as this is intentionally the "whatever
integer" type, it would be used anywhere "whatever" is needed (which
certainly will not be everywhere an integer type is needed, so there will
still be conversions, but those would be required anyway whether you write
it his way or my way).

>
> > Also -- in this example, you've defined your own integer type so that
you
> > have the flexibility to change it later.  Isn't there still always a
problem,
> > in that you still assume that you'll always be able to use the same type
for
> > all the same things?  Let's say you go and use My_Int everywhere instead
of
> > Integer.  Now you find that for certain of those uses, the current
definition
> > of My_Int isn't going to cut it.  Well, the ability to change the
definition
> > of My_Int only helps you if the new definition is also what you want for
all
> > the uses of My_Int.
>
> You have the exact problem if you use the "whatever" Integer. As soon as
some
> of the uses differ from the "whatever" usage, then you have to rename
things
> anyway.

Yes sir, that's absolutely right -- you have the same problem!  The point I
was trying to make (and didn't make very well :-) was not that Integer makes
it any better, but that My_Int *doesn't* make it any better.  Really, the
problem with what I wrote was that I contradicted myself -- if indeed all
the uses of "whatever integer" don't care, then they cannot possibly be
broken if the definition changes for the sake of one usage that suddenly
starts to care.  But as you point out, the right solution is not to change
the definition anyway, it's to use a different type.  Changing the
definition only obscures the code, since now we have a documented intent of
"don't care" even as it now does care.  So My_Int is not better with respect
to "resilience to change".