First of all, your users don't have to use it. That's the whole point of the Object Oriented Paradigm - you hide implementation from the users.
Except that on a large game project that uses one of my libs the chances that they'll need to modify my lib in some way are pretty good.
Actually I would suggest nothing of the sort. I would simply import it into whichever sources I needed it for.
What's the difference between import and include? I thought import was only for modules, but the help file indicates otherwise. Using Import and placing it in the modules directory, is what I meant by a lib.
I think I did a test with include once, and it did not do what the help file says it does... Include the source file at that location in the code. It didn't work in the middle of a for loop or in a function if I remember. So I think there's some subtle difference between the two.
Maybe Import allows you to import things in any order you want and they will work? I seem to recall in my Lego game I had to seperate my functions from my types in several libs which were dependent on one another, because I had to specify the types before the functions that called them. So I had to include the types for both libs before the functions that would use them.
Does Import avoid this issue? Does it do anything to protect your code at all above and beyond what include does? The help file example doesn't really help much here.
Perhaps locals in an include become acessable to the main program, while locals in an import do not?
[quote]
Also, I wish people would stop suggesting folks alter the default libs.
Who suggested that?
[/quote]
You:
all you have to do is change the NextObject Method in TListEnum to return links instead of values.
Other people have suggested making similar changes to the main modules when something didn't work the way I wanted. Like changing a private declaration to public. But it would be crazy to do that.