Re: symbol resolution (was:EuCOM : Attn Matt : String Return Value)

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

Pete Lomax wrote:
>
> I am quite worried that absolute torrents of the warning you propose will
> occur
> in legacy code. 

Heh.  I added the warning and tested against eu/ec/backend.ex.  It was
an absolute torrent of warnings.  And it requires some code reorganization.

Basically, the top-level .ex file includes files based on what it's doing.
And there are some functions and constants that are defined differently
based upon this.  But, of course, the users of these identifiers just
pick up whatever is there, since there's no such thing as a conditional
include.

So I created two additional files, common.e and mode.e.  I made common.e
because backend.ex doesn't use global.e.  And I moved several things to
global.e to allow consistent include statements (in order to get rid of 
the warnings).

mode.e is used to facilitate the modularity, so that instead of code 
calling things like InitBackEnd() directly, they end up calling the 
version in mode.e, and the files where the real InitBackEnd() are declared
use set_init_backend() to pass a routine_id.

I've committed the changes to a branch in the repository:
http://rapideuphoria.svn.sourceforge.net/viewvc/rapideuphoria/branches/mwl/source/

You might say, "Who cares, this isn't a library!"  And I'd say, "Not yet."
One long term goal of mine is to be able to embed the interpreter into
your applications (I've done this with ooeu), at which point it will be
important.  By making these changes, we can be assured that we won't get
any namespace resolution problems originating from within the interpreter
code, which, IMHO, is a duty of a library developer.

Matt

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

Search



Quick Links

User menu

Not signed in.

Misc Menu