Complexity nomenclature

[Walter Bright via Digitalmars-d]

On 12/4/2015 7:11 AM, Jonathan M Davis wrote:
> On Friday, 4 December 2015 at 14:51:40 UTC, CraigDillabaugh wrote:
>> My personal preference would be not to have the complexity in the names, as I
>> prefer shorter/concise names. Typically when I am writing code using
>> containers of any sort I will check the documentation to determine what the
>> cost of the operations I need is and base my choice off of that. I would think
>> (hope) most others do this too.  However, I don't have a strong objection to
>> the what is being proposed.
>
> std.container puts linear and/or stable in some of its names and then creates an
> alias to whichever one makes sense as the default where the alias doesn't have
> linear or stable in the name. e.g. linearRemove becomes remove via an alias.

Excessive use of aliases is a problem in and of itself - for example, trying to 
use a debugger with it, or examining the object code.


> But actually using something like stableLinearRemove in code (or
> stable.linear.remove) becomes hideous _very_ quickly. No one is going to like
> it,

I agree. Having such long names consisting of repeated use of the same words is 
a problem.

I suggested in the pseudo namespaces thread using template parameters to express 
characteristics, as in:

     remove!(stable, linear)

with sensible defaults so most of the time the user would just use:

     remove

Generic code could use the parameters. Another alternative is to have attributes 
for the algorithm:

     @stable @linear remove() { ... }

and then generic code could test for those attributes.