Re: another look at namespaces

new topic     » topic index » view thread      » older message » newer message

Thanks to everyone who helped develop the recent proposed
namespace refinement. (I won't name names since it's
a bit fuzzy who came up with what idea when).

I think it makes sense that when there are conflicting
global symbols, and one of the symbols was intentionally
defined or included (directly or indirectly) by the
current file, while the other symbol(s) are visible for
reasons outside the control of the current file,
then it's pretty clear which symbol the current file
wants to use. It's already the case that if a symbol is
directly defined in the current file, that symbol
will be used, and there will be no conflict. We'll
extend that idea to symbols included by the current file.

I'll implement this refinement to the namespace
feature for the next release. Matt, I'll be interested in
seeing your code, but keep in mind, for me there are many places
affected by any change to symbol look-up. All are coded
slightly differently.

    - main parser/scanner look-up for Interpreter and Translator
    - Interpreter routine_id() look-up
    - interactive trace(1) variable look-up
    - binder look-up
    - Translator routine-id() look-up

The last 3 are not part of the Source Code product.

Regards,
    Rob Craig
    Rapid Deployment Software
    http://www.RapidEuphoria.com

new topic     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu