Re: Euphoria vs. other programming languages
- Posted by jimcbrown (admin) Mar 12, 2009
- 1311 views
Inclusion of libraries happens usually at the top of the main file, because they are used almost from that point on, specially if they require some initialization.
For subfiles, ie files you include so as to split up your own code into moe manageable chnks, I don't think this is so clear cut. It is clearer to declare a variable or a file close to the point it is used.
This has never been the case for me. This appears to be a rare practice.
Not true.
file1.e includes file2.e file2.e includes file3.e file3.e includes file4.e
Identifier x is defined as public in file4.e . Where is it seen from? You have to follow th chain of public inclusions to guess whether it is visible in file1.e or not.
global was more straightforward, as you need only grep or similar utility. Some symbols must have less broad a scope, of course, but public is clearly not a good answer to the issue.
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.
Not true again.
If you expand the visibility of some symbol in a deeply nested file, by adding another public qualifier to an include statement, you change the visibility of all symbols in that file. Not really the desired effect sometimes.
Right, public include is not meant to be used to expand the visible scope of a single symbol. public include isn't meant to be used outside libraries, and only then to allow a single file to expose all the public symbols in the library (regardless of which files originally declare the public symbols) - in effect allowing you to turn a huge 1-file library into a set of more managable smaller files.
public include's can be deeply nested, but this is as bad a practice as using global. public include should only be used in the main api file of the library (the one that is included to get access to all the routines of the library) and not elsewhere. Even in this usage, the public include should be limited to one leve.
Problem not solved, since redefining other global symbols - from instance from the standard library - was just as common as redefinng builtins.
What does that have to do with anything?
Yes, they are. Declare before use had been one of the strength of the language.
Note that I only agree to "forward references are bad in general". With proper restrictions, they are handy but yet not too harmful. And forward referencing is obviously needed, if only to remove the need for cyclic inclusions.
But you digress.
We have different faiths it seems. In large programs, this is very unpractical.
Why?
Any small library will be one file, which when included directly in the main app, there is little functional difference between global or public.
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.
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.
Not always and not in an easy to trace manner, see above.
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.
