Re: Euphoria vs. other programming languages
- Posted by mattlewis (admin) Mar 12, 2009
- 1340 views
Assuming file1.e is the main file that I am editing, why do i care that file2/3 have x?
If i want to use x in file1.e I should include file4.e in file1.e anyways. I should not rely on file2.e including file1.e for me, or any other automagic.
So, if x was in file3.e and was then moved to file4.e, you want to review all your code? You'll understand that O don't quite agree to this being good for maintainance.
I don't know who 'O' is, but presumably there was a good reason for moving it that made sense. In that case, yes, I would expect you to do this, or at least try running the code to see who can't see it. Are you suggesting that you often move things around in files without thinking of the consequences?
If you think of your files as semi-independent modules, this all makes sense. If you simply see them as a way to keep any one file from growing too large, then you probably have bigger problems maintaining your software.
In a nutshell, [public include] is not very useful, and has been overadvertised as solving isssues it doesn't.
I disagree. It solves precisely the issues it was meant to solve. And by that I mean it gives authors of multi-file libraries the flexibility to share some symbols only amongst the library itself, and to share other symbols within and without the library, all without polluting the global namespace.
What problems do you believe are being over advertised?
Any significantly large multi-file library will exposes all public symbols in the api file, which the main app can pretend is a single file library.
What is "the API file"? Exposed identifiers may be defined in any subunit of the library, and which file it is might change without notice.
The API file would be considered as the main file in a library. Win32Lib.ew, for instance. In other words, whatever file your documentation tells users to include. So long as that file uses public include with any library files with publicly scoped symbols, the end user doesn't have to care about which sub file actually defines the symbol.
If you are lazy, you can include everything at once in a getitall.e and then public include getitall.e - this is bad practice, however.
Let me rebutt this with a single example. In win32lib, the getDC() function, which is used extensively, is defined in w32resources.ew, which win32lib.ew includes. Now, don't expect anything to work if you just include that file.
Why would we? Is that file documented? To my knowledge, users are told to include win32lib.ew. This example doesn't rebut anything, but shows that you should use a library the way the author intended, or you're on your own, and some things probably won't work.
Only if the ancestor file declares a symbol in public scope AND that symbol is still visible by the time we get to the usage.
In 3.1, this problem still existed if both symbols were global, only we got an error message because 3.1 wasn't smart enough to figure out which symbol to use.
In 3.1, this problem still existed if the file had a local symbol with the same name.
Which, for the global vs global case, was requried for 3.1 as well.
Agreed. forward referencing changed how the global keyword works. This is a good reason for all major libraries to change to the new public keyword instead.
A good code breaker for no benefit, you mean.
Most code won't even break due to these changes. And there is plenty of benefit, even if you can't comprehend it.
Matt
