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