Pseudo namespaces

Steven Schveighoffer via Digitalmars-d digitalmars-d at puremagic.com
Thu Dec 3 18:59:12 PST 2015


On 12/3/15 9:40 PM, Andrei Alexandrescu wrote:
> On 12/03/2015 09:37 PM, Steven Schveighoffer wrote:
>> On 12/3/15 9:20 PM, Andrei Alexandrescu wrote:
>>> On 12/03/2015 08:59 PM, Steven Schveighoffer wrote:
>>>> On 12/3/15 8:01 PM, Andrei Alexandrescu wrote:
>>>>> On 12/03/2015 05:59 PM, Steven Schveighoffer wrote:
>>>>>>
>>>>>> alias stableLinearXxx = linearStableXxx;
>>>>>
>>>>> Doesn't scale. -- Andrei
>>>>
>>>> To what? How many nested namespaces are you planning?
>>>
>>> Many functions, not many namespaces. One declaration per function is
>>> fail. -- Andrei
>>
>> It seems worse with namespaces:
>>
>> 1. a linear namespace
>> 2. a sub namespace for linear.stable
>> 3. a function definition for linear.stable.foo
>> 4. a stable namespace
>> 5. a sub namespace for stable.linear
>> 6. an alias (I'm assuming you're not repeating the function definition
>> here) for stable.linear.foo to linear.stable.foo
>>
>> Perhaps my strawman isn't what you were thinking, let me know. It
>> appears to me that you will need more machinery for namespaces.
>>
>
> I don't get your point. Mine is there are many methods and few named
> scopes aka namespaces. So I'm okay to scale declarations linearly with
> number of named scopes but not with number of methods. -- Andrei
>

I think I see, all you need is a way to generate the aliases that will 
be both linear and stable. I can think of nasty ways to do this with 
opDispatch.

FWIW, I don't believe this complexity of API is worth it. It may be you 
have all this wonderful mechanisms to specify exactly the runtime 
requirements for your algorithms -- and nobody uses it because they 
either a) have a specific container in mind, or b) don't care to 
constrain the container type being used. I think there are a few basic 
guarantees to worry about, and anything beyond that is overcomplicating 
things.

-Steve


More information about the Digitalmars-d mailing list