Canonical/Idiomatic in memory files

[Paulo Pinto]

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.