Re: symbol resolution (was:EuCOM : Attn Matt : String Return Value)
Pete Lomax wrote:
>
> Matt Lewis wrote:
> > It's true that some third party (multi-file) libraries may require some
> > rework. I didn't find any warnings with win32lib, however, which has to
> > be the most used and most complicated of them all.
> It has not escaped me that far more effort has probably been spent on avoiding
> these kinds of issues in win32lib, via conventional methods, than all other
> Eu code in existence put together! With hindsight it was a very poor choice
> of challenge! On a hunch I looked in Arwen and was surprised I could only find
> one apparently unnecessary global, NUMCLASSES in classes.ew, and even that
> seems
> like a typo as only classes.ew uses it.
>
> Perhaps indeed this problem is being blown out of all proportion.
>
> Or perhaps this is the very reason that win32lib is not broken up into more
> manageable pieces, say printing, fonts, listviews, treeviews, mouse,
> properties,
> datetime, scrollbars, bitmaps, etc.
>
> Regards,
> Pete
Very precisely so.
See, in v0.70.x, the former w32support.e had grown to a jumble of 6000+ lines
covering much unrelated issues. This is why I suggested and implemented a breakup
of the file into w32memory.ew (the structure engine, quite extensively enhanced)
and w32utils.ew (everything else).
I had been informed of EuCom including directly w32suport.e, which is why there
is a wrapper file of that name in the current distribution. As a result,
include w32support.e
still has the expected effect, but
include w32support.e as mem
no longer does.
Likewise, spinning off w32forms.ew, which appeared to be quite natural, wasn't
that easy. I managed to make public half of the symbols that went global in the
process, but not some others. This is why I'd insist on preventing "private
global", or inernal, symbols to break havoc on an application.
Under the current system, you have to lump everything in a single file or expose
unwanted globals. That's how we had a 33000+ line win32lib.ew.
Introducing "import", or "local include", or whatever, seems to me more useful
than the planned change in namespace semantics, though I'd keep the idea of
inherite namespaces - so that a namespace acts like a package identifier.
If we were redesigning Eu, I'd suggest making include bloxk any global in
included files, "global include" being used to lift this restriction. But this
would break too much code I'm afraid, so let's go with "import", hoping most
library writers will soon update. Note that my solution spares the user having to
wait for an update, while avoiding to touch any file he already has.
CChris
|
Not Categorized, Please Help
|
|
