Re: Text_IO, was: Re: Something I don't understand

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 14-02-18 11:31 , Dmitry A. Kazakov wrote:
> On Tue, 18 Feb 2014 11:00:44 +0200, Niklas Holsti wrote:
> 
>> On 14-02-18 10:40 , Dmitry A. Kazakov wrote:
> 
>>> because texts are formatted differently depending
>>> on the medium. Different mediums deploy integrated mechanisms of
>>> formatting. E.g. paging is postponed until rendering if the medium is HTML.
>>> Alignment with proportional fonts is not about fields and decimal places,
>>> etc.
>>
>> Exactly. I meant that the type "Text" would represent text abstractly,
>> according to its logical structure, not in rendered form.
> 
> You mean text buffer like in GUI?

Possibly so, but I'm not familiar with GUI text buffers. It sounds like
a similar thing.

> To me text buffer, stream, file, string are all instances of the class of
> types over which Put dispatches. OK, we can call the abstract root type of
> the class "Text."

Perhaps Put would just be overloaded for these types. It depends if you
consider the types a class, or not. I'm not sure what is best.

>> The final
>> "Put" would then render according to the output medium.
> 
> Yes, that Put would be an implementation of the primitive operation defined
> for the class Text.

I would make Text a type, not a class. This would avoid the need for
multiple dispatch on a controlling Text parameter.

I'm thinking of two levels of "Put":

   Put (To : in out Text, Item : in String);
      Add items to a Text, building a logically structured Text,
      but without rendering it yet. This wil probably need
      some concept of "points in a Text where more stuff can
      be inserted" so that the Put can preserve or extend the
      logical Text structure.

   Put (To : in out File; Item : in Text);
      Render the Text into some external File.

The Text buffer intermediary means that each level of Put can (if
desired) be dispatching on one of the parameters, without needing
multiple dispatch.

> I think it is only logical for a strongly typed language to map this kind
> of stuff onto types.

I agree.

> This search for other "ways" (aspects, generics etc) is really damaging the
> language.

I don't agree. I see aspects as strengthening or broadening the type
concept, and generics as a meta-type level. But I must admit that I have
lately been using generics less often and have instead used classes and
dispaching more often. However, I think that generics are useful and are
not entirely subsumed by classes.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .