UFCS for D

[Nick Sabalausky]

"deadalnix" <deadalnix at gmail.com> wrote in message 
news:jl47k0$1old$2 at digitalmars.com...
> Le 30/03/2012 12:57, foobar a écrit :
>> On Friday, 30 March 2012 at 10:22:18 UTC, Walter Bright wrote:
>>> On 3/30/2012 2:15 AM, Nick Sabalausky wrote:
>>>>> Andrei and I have talked about it, and we think it is because of
>>>>> difficulties in breaking a module up into submodules of a package.
>>>>> We think it's something we need to address.
>>>>
>>>> Eh? Other people have voiced concerns over that since waaay back in 
>>>> even
>>>> pre-D1 times. In particular, many people have argued for allowing
>>>> modules
>>>> with the same name as a package. Ie: you could have both module "foo"
>>>> and
>>>> module "foo.bar". The reasons they gave for wanting this are right
>>>> along the
>>>> lines of what you're talking about here. Eventually they got the 
>>>> message
>>>> that it wasn't gonna happen and they gave up asking for it.
>>>>
>>>> Or is there a separate problem you're refering to?
>>>
>>> No, that's it. What brings it to the fore is, as I said, the
>>> kitchen-sink module that is becoming prevalent.
>>
>> I'm confused. I thought that The kitchen-sink approach was a deliberate
>> design decision. I also don't see how the language is at fault here -
>> some libraries opted for a all.d module that public imports the other
>> modules which cleanly solves the problem.
>>
>> This can be trivially solved by a convention of adding a _.d or all.d or
>> whatever agreed upon module at the package level. Sure, the above
>> mentioned enhancement will remove the need for this extra tiny step. But
>> this is merely eliminating a minor inconvenience, not some huge flaw of
>> the language that prevents good design and proper organization.
>
> all.d this the de facto standard here. I think it should become an 
> official guideline.

Another option is to do this:

    module foo;
    public import  foo_.bar;
    public import  foo_.baz;

    module foo_.bar;
    [...]
    module foo_.baz;
    [...]

The benefit of that is that the user doesn't even have to know or case about 
any such conventions (actually I might do that with my libs intead of the 
all.d I've been using). The (somewhat small) downside though, is that 
anything in "foo.d" is not in the same package as "foo_/*.d", which could 
matter on things with the "package" access specifier. But that's easily 
solved by keeping "foo.d" limited to imports only.

Of course, *all* this stuff goes away if we could just simply do:

    module foo;
    public import  foo.bar;
    public import  foo.baz;

    module foo.bar;
    [...]
    module foo.baz;
    [...]

Which IMHO seems like a simple "removing undue limitations". But maybe 
there's technical problems with that I haven't thought of?