Re: symbol resolution (was:EuCOM : Attn Matt : String Return Value)
Pete Lomax wrote:
>
> Matt Lewis wrote:
> > I think I never really looked at it. Looking at it now, I think I disagree
> > with some of the premises. I briefly described to CChris what I thought
> > was a reasonably simple way to encapsulate. The only change would be
> > to change from "include" to "import."
>
> But what happens when a file contains both globals that you want the whole
> world
> to see and globals needed for private communication?
>
> Hacking the files into "include" and "import" pieces is probably not a goer
> - wanna try that with win32lib?
Short answer: yes.
I agree that there would be significant work for something like win32lib,
but any encapsulation scheme is likely to require this for something like
win32lib. In fact, I suspect that this would be a good way to go,
because it would help to make the interface more independent of the
implementation.
> > I'm wondering about the justification for this requirement:
> > "z2 is visible in f2 and f5 but nowhere else"
>
> A simple example is a routine_id. f2 wants to (forward) call something in f5
> so the standard trick is to declare a global in f2, and set it in f5 after the
> routine definition. Nothing else needs to know about that routine_id, but
> there
> it is happily polluting the global namespace, forever waiting for an
> unsuspecting
> victim.
I guess I'm not as worried about this as you are. Another (similar) way
to do this is to have a "setter" routine in f2 called by f5 (or whomever
is using f2). Again, this could also be solved by organizing the library
by interface vs implementation files.
Could you expand on the 'unsuspecting victim' a bit more? Are you concerned
about conflicts? Bugs where someone wrongly uses the variable? I think
I'd like to point out that with the newer symbol resolution rules, it
should only be an issue for *users* of the code, not additional 3rd
party code that is put into the same app.
> > Other files include f2, but apparently only want to see certain symbols
> > from f2 (the file where z2 is declared). While I think that your system
> > is interesting, I'm not convinced that it's solving a real problem.
>
> The trouble with real problems is that they have more than one solution 
> I accept it is more of a reaction to the oft discussed "pollution" than any
> real issue I am struggling with, and in fact I wrote the data hiding challenge
> to get a better grip on the problems being moaned about. If you can think of
> a better example...
Fair enough. I think the best example might be in actually doing it to
something like win32lib (though maybe a bit smaller, of course).
> It may help to reiterate the idea behind this:
> Someone writes a lib of some sort. Perhaps this is designed in from day 1,
> perhaps
> a user experiences performance problems, but someone writes f7 as an optional
> bolt-on and litters the code with counts f2called, f3called, etc.
> f7 processes all this data at the end, maybe checks that #opens = #closes,
> bytes_allocated
> = bytes_freed, or whatever. Maybe you had a go at writing a central
> collectStats()
> routine but it made the lib 50% slower whereas lots of f2called+=1 etc made
> no noticeable difference. Anyway, the idea is to gather data all over the
> shop,
> which is only used in one place.
My first thought about this is that it's all debug code that should
probably be removed before release, so I'm not sure that it's a good
example.
> There are obviously other classes of problems to be thought about as well.
Yes. To expand on why I'm for adding some sort of data hiding to euphoria
(which probably isn't saying anything you haven't already thought or said):
If you expose something, then it's almost guaranteed that someone will
use it, whether or not they should. This can cause problems if you
later decide to change something that someone else depended upon.
Take a look at Raymond Chen's blog for some great examples in the MSWindows
world.
That's not to say that someone won't go in and abuse your code and expose
things that you didn't want exposed, but that's a different issue
altogether. Allowing things to slip out makes it more painful to
change things later--you have to balance upsetting your users who took
advantage of exposed, but undocumented and unintended features of your
code with the benefits of the change.
Win32lib, for example does all kinds of stuff under the covers that most
people have no clue about (and I've been away long enough from the code
that I probably wouldn't recognize it anymore, either). But you can
still basically use the code like you did 5 or 6 years ago. However,
we can all witness the problems that I've had every time it's changed
the way the memory/structure code. EuCOM depends on those things
(because it's really good code), and I don't really see a great solution
in there. And those things were meant for external coders to use them,
but we can imagine a similar situation with code not meant for external
consumption.
> > I guess we probably need to declare what problem we're solving. My idea
> > is that we want to be able to use symbols across files, but to have
> > a 'firewall' to limit their visibility to users of those files. One
> > reason that I like this scheme is that it requires very little be done
> > to get this effect, and it's done in a very straightforward way.
>
> I would not be against this, but once you set up a firewall for one purpose
> it seems hard to add a different one for the "bolt on" case, should they
> overlap.
I think it's actually pretty easy to punch holes in the firewall. Just
add an include statement. Of course, by doing so you should realize that
you're no longer using the library the way it was originally designed,
so you need to be aware of the consequences (not all of which are
necessarily bad).
Taking another look at your example, I'm concerned with the shared scope
identifiers. What do we do when those start to conflict?
Other languages have more "natural" ways to deal with this problem. In
C, you have header files, and in [most?] object oriented languages, you
have different scopes for class members that help with encapsulation.
Maybe we need to add the concept of header files to euphoria? To include
a library, it defines which files to include, and which symbols to be
exported, without actually causing any IL to be generated, so you don't
have to write any "interface wrappers" when you lay out the code.
I doubt this is a good idea, but it should probably be considered.
And perhaps in addition to your 3 criteria:
1: Unambiguity and Least Surprise
2: Zero impact on legacy code
3: Minimal performance impact
4: KISS
It's that #4 that probably worries me most between your and CChris'
encapsulation proposals, though I find yours a bit simpler.
Matt
|
Not Categorized, Please Help
|
|
