On Wednesday, 29 May 2013 at 11:00:23 UTC, Russel Winder wrote:
> On Wed, 2013-05-29 at 00:32 -0700, Walter Bright wrote:
> […]
>> This is incorrect. They are implemented as sort of "second class citizens" in the current name space. This means that any declaration in the current name space overrides any in the import name space. If the name is not found in the current name space, and is found in more than one import, an ambiguity error is generated.
>
> OK so this is a quasi-namespace import which helps. Dealing with
> multiple names in imports by just creating a compile error stops tragedy
> but seems a little awkward. It does reinforce my belief in individual
> importing of names though.
>
> […]
>> It's equivalent to:
>>     struct Tuple { int lines; int words; int chars; }
>> which is much more efficient than a dictionary.
>
> Interesting. I probably should already have known this. I suspect
> further exchanges on this should move the to learn mailing list!
>
> […]
>> You just need to get the component programming religion! and get away from using FILE*. There isn't anything fundamentally different from using a fake FILE* and using a template with a different InputRange. If that's still unacceptable, you can create an InputRange that is a class with virtual functions empty(), front(), and popFront(), then use derived classes for the File or string.
>
> I'm not sure I would call it component – didn't components die in the
> 1980 when no-one could agree what a component was?
>

They reborned in the form of interface based programming, COM and Web APIs.

Another example just came up:

http://dlang.org/phobos/std_process.html#.executeShell

you can redirect to Files, but not easily to strings or pipes or something you can handle in memory. Blargh.

On 5/29/2013 4:00 AM, Russel Winder wrote:
> I'm not sure I would call it component – didn't components die in the
> 1980 when no-one could agree what a component was?

Everybody has a different definition of "component". What I'm talking about here are interchangeable blocks of functionality which encapsulate input and output.