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?
I had missed that there was the possibility of polymorphism over
sequence of strings and open file. Which is silly as that is exactly
what you can do in Python and which I do a lot. Doh moment.
Thanks.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
