Re: for S'Image use Func??

[Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de>]

On 5/6/10 7:10 PM, Warren wrote:

> Finally, there is actually a third question- more along
> the lines of "Should this language feature be used
> in this manner?", or is it preferable to just code your
> own along the lines of (which is what I presently use):

Apologies for the length of the following. In short:
not in this manner, use Ada instead, don't tweak
the language, no need.

[1. mislead assumptions].
If, as Bob has said, programmers discover 'Image before
they discover Text_IO.*_IO and Text_IO.Editing, then there
is something wrong, indeed---with Ada's appearance before
them!  If you want them to be able to write an output
line quickly, give them a package! Don't misuse 'Image.
They may be quite used to industry standard logging packages
and such, no hurdle there.

[2. 'Image *and* 'Value are paired and have a purpose,
or contract].
Is 'Image a formatting function? I don't think so.
Is it intended to be one? I can't imagine that, not in any
non-trivial sense of the word "formatting".
  'Value is its counter part. Is it a scanning function?
I don't think that, either, for the same reason.
And if 'Image and 'Value come in pairs, redefining
one without the other seems wrong. So what should a user-
defined 'Value be? Shouldn't it agree with what the LRM
implies?  Should not the new Generic_Dispatching_Constructor
be its equivalent?
   Should we, in spite of all this, deprive ourselves of
what we routinely do in other cases? That is, ideally we
express the purpose of a function call with suitably and
freely chosen names for an implementation that meets our
needs.

You said you were too lazy to ... and therefore wanted
to adapt something half related to your purpose.
You might be doing yourself (and your readers) a disservice.
To see this: What is the contract if 'Image, expressed
as pre- and post-conditions?  What could this description
be in the standard if programmers we invited to dismiss
printing packages in favor of user defined 'Image, thereby
manipulating the contract of 'Image?

[3. Use normal Ada for polymorphism].
If I wanted polymorphic behavior of numbers,
I'd make them have a suitable type. Or wrap them in
one where necessary, e.g. during I/O. Or mix them with
a package that provides "polymorphic appearance" like
Dmitry's or, IIUC, PragmAda.

You can say

   type Derived_Num_Type is new <some number type>;

   overriding
   function Image (X: Derived_Num_Type) return String;

where Derived_Num_Type is both tag-less and has an
Image operation that makes strings the way you want
them.

[4. no need].
Why do Ada programmers forget Ada language
principles whenever it comes to basic values? :o(
Is it not obvious that using 'Image in ways it was not
intended to be used makes the program text misleading?

I can understand that the customer is always right
and that Ada vendors would quite naturally consider
tweaking 'Image.  But I also hope they have ways to
provide alternatives based on existing Ada that will
serve both their customers and Ada. Certainly you know
what your image functions should do.  So write them.


-- Georg