UFCS for D

[deadalnix]

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.