Re: String_Holder ?

["Randy Brukardt" <randy@rrsoftware.com>]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:9lgdtoFi8U1@mid.individual.net...
> On 11-12-22 11:08 , Natasha Kerensikova wrote:
>> On 2011-12-19, Randy Brukardt<randy@rrsoftware.com>  wrote:
...
>>> 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.

I personally tend to a bit less abstraction, as I mentioned earlier this 
week, there is such a thing as too much. But this is clearly personal 
preference -- there is no right or wrong answer. But...

...
>> 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?

Niklas's testing joke actually was my point. The cost to write, test, and 
maintain 50 lines of code is many times that of writing, testing, and 
maintaining 0 lines of code. That's true whether you are testing to 100% 
coverage or just simple existence tests.

Back when I was starting out, there were widely quoted studies that claimed 
that programmer productivity was about 100 lines per day, no matter what 
language, tools, or targets were involved.

That seems silly (I've written several thousand lines in a day), until you 
start to think about all of the non-coding things that one has to do in a 
typical workday. After all, I've spent more than 4 hours tracking a single 
code generator bug that turned out to require one line of code to fix 
(adding an additional condition to an if statement). And there's 
documentation and meetings and customer help and backups and the occassional 
power failure -- all of which reduce the productivity.

I don't know if that number still holds or whether something has changed it 
going forward, but even if it has doubled, a 50 line package is an 
investment of 25% of a day. One imagines that time could be used for 
something else -- it's not just in a vacuum.

> 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.

It's less that than cogentive overload. You have to at least have a concept 
of what each type is before you can reason about a piece of code. Naming 
helps here, of course, but using a familar type in the intended way is even 
easier to understand.

And I guess that is my major objection: you are creating a type that adds 
nothing to the capabilities, but you are adding something additional that 
has to be understood to work on your code. Moreover, you are forcing a 
choice between these two ways (String_Holder vs. Unbounded_String), and 
reason for choosing one or the other would not be obvious. (Especially given 
that Unbounded_String's entire reason to exist is to hold strings in 
components and the like.) We always hear complaints about having multiple 
ways to do the same thing in the Ada Standard, and that applies just as well 
to your own code.

Anyway, none of these reasons are show-stoppers (it's your code after all), 
but I think it is important to remember that there is a cost to every line 
of code you write, and there had better be an offsetting benefit to that 
code. If you can't describe the benefit clearly, then put away the keyboard 
and rethink what you are doing.

(Of course, you may have a different idea of a benefit than I do.)

                                               Randy.