Re: String_Holder ?

[Natasha Kerensikova <lithiumcat@gmail.com>]

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.

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?

> 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. Am I missing
something in my cost evaluation?

The alternative proposed somewhere else is:
type String_Holder is new Unbounded_String;
with subprogram renames to remove Unbounded_String-specific parts for
better abstraction.

I feel it to be about as expensive, 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.

So what am I missing there?


Thanks for your insights,
Natasha