Re: String_Holder ?

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

On 11-12-22 11:08 , Natasha Kerensikova wrote:
> Hello,
>
> On 2011-12-19, Randy Brukardt<randy@rrsoftware.com>  wrote:
>> "Natasha Kerensikova"<lithiumcat@gmail.com>  wrote in message
>> news:slrnjerndj.1lme.lithiumcat@sigil.instinctive.eu...
>> ...
>>> Assuming it does make sense, am I right in thinking it's better to have
>>> such a type, even if it's a thin wrapper around Unbounded_String,
>>> instead of using directly Unbounded_String?
>>
>> What exactly is the advantage of your Holder type over Unbounded_String
>> (other than shorter operation names :-)?
>
> As I answered somewhere else in the thread, having a name in line with
> the function rather than some irrelevant (in that case) object feature.
>
> I would rather have String_Accumulator when I'm building a string by
> repeated appends, String_Holder when I'm only interested in keeping a
> reference of it, String_Buffer or String_Queue when I want to append
> data to be processed by some other subprogram that would retrieve it
> from head, etc.

I think this is a good principle.

> Even though they can all be implementation with Unbounded_String under
> the hood, the more specific type allows better self-documentation of the
> code, and hides Unbounded_String operations that are not natural for the
> given function (e.g. String_Holder is supposed to reference an immutable
> string, so any operation that change the underlying Unbounded_String
> would break stuff).
>
> And in case I need extra performance, for whatever measure of
> performance (be it CPU usage or memory usage or latency consistency or
> anything else), I can change the implementation of that specific type
> without affecting any other function.
>
> Am I missing something that would be a serious drawback for that way of
> doing things?

Adding a type "on top of" Unbounded_String, with operations that are 
implemented by calling operations of Unbounded_String, can of course 
slow things down a bit, unless the additional calls are inlined. Whether 
this is a serious drawback depends on your context.

>> So I don't understand the point -- and you clearly need a reason to write a
>> new package here rather than using the built-in one.
>
> Do I really need a reason? I tend to consider a 20-line specification
> and a 30-line package body as something extremely cheap.

I agree. Unless you need to unit test everything to 100% coverage :-)

> Am I missing something in my cost evaluation?

The program may be a little harder to understand for people who are used 
to think in terms of real types rather than abstract (private) types. 
When such people see a declaration like "Var : X_Type;" they need to 
know what X_Type "really is" before they understand how Var can be used.

>
> The alternative proposed somewhere else is:
> type String_Holder is new Unbounded_String;

I think I suggested that, but there may have been others.

> with subprogram renames to remove Unbounded_String-specific parts for
> better abstraction.

I did not suggest that. I assumed that you are coding this yourself, and 
that you would use, and perhaps rename, only those operations of 
Unbounded_String that are appropriate for the derived type, and avoid 
others. But removing the other operations is more thorough and stricter. 
If this is a requirement, I too would opt for a new type that is 
implemented by means of Unbounded_String but is not derived from it, 
otherwise the number of operations to be removed could be large.

>
> I feel it to be about as expensive,

Calling an operation that a derived type inherits from an ancestor type 
does not introduce an additional layer of calls, I believe -- the call 
goes directly to the operation of the ancestor type.

> except that there is one package for
> the entire project, while the alternative is per-client-package (unless
> it gets its own package), so it scales differently.

I don't understand how the number of packages is connected to the 
question of deriving the type or creating a new type.

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