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.
