Re: Euphoria vs. other programming languages
- Posted by CChris Mar 12, 2009
- 1433 views
Currently from anywhere. Previously only from a known part of the set of source files. This makes a whole differece on average, and it is detrimental to the maintainability of 4.0 code.
In large programs, I typically have to use grep to figure out which file defined the symbol that i was trying to used. I have done this since eu 1.5!
Since the normal practice is to place all includes at the top of the file, there is no practical difference.
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.
Do you mean that you don't know which files are in the source set? Come on, let's talk about real life.
This happens to me on a daily basis. ;) Luckily I have grep ... and ls ...
Most editors have a search in file/folder ability. In 3.1, you need to simply list those statements. In 4.0, you need to see how they chain to one another. Can this be portrayed as simple?
Why is it necessary to check the entire chain? You just need to check two types of places: where the symbol is being used and where the symbol is declared. grep searching is good enough for this (and 3.1 did not really make this any easier than 4.0)
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.
I really can't understand what your point is in bringing this up. Are you concerned at determining who can see a particular symbol from the perspective of that symbol?
Yes, because it becomes tricky and error prone to adjust it.
It is really easy to expand the visibility of the symbol, so I assume you are talking about trying to hide it from more files.
How often is this really necessary?
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.
As you mentioned, everyone can see a global symbol. That's a very blunt instrument, and has consequences that make it a lot less useful than it originally sounds.
Wrong, both in 3.1 and 4.0.
In 3.1, a global symbol can be seen any place parsed after it has been defined, not everywhere. Lots of code use this feature at their advantage.
The only major way this feature has been used is to allow redefinitions of builtins to call the original builtins. Since we have an alternate way to do this (the eu: namespace), problem solved.
Problem not solved, since redefining other global symbols - from instance from the standard library - was just as common as redefinng builtins.
In 4.0, a global symbol is further hidden if defined by an ancestor or sibling file.
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.
You need to add in extra include statements to see it.
Which, for the global vs global case, was requried for 3.1 as well.
This has two drawbacks: 1/ vastly increasing the occcurrence of cyclic inclusion, which in turn require badly designed forward references to avoid errors;
In other words, 1/ is not a drawback unless you take as a given that forward references are bad in general.
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.
2/ vastly decreasing the reusability of include files, since they must very often bear an explicit include directive for their parents, even though the aim is to allow several distinct parents, some of them user supplied, to include them.
This is not an aim. All files should explicitly include the files that declare the symbols that they wish to use. This is good practice, this is how it should work.
We have different faiths it seems. In large programs, this is very unpractical.
The exception to this is large multi-file libraries, which is what public include is meant to be used for. One file serves as the file to include directly in the user app, and public include exposes the right symbols to the user.
Not always and not in an easy to trace manner, see above.
Further, even though the "global" keyword has been left in, its semantics have changed, to the effect of breaking most complex libraries available. win32lib is perhaps the most obvious example.
R. Stowasser has posted many instances of problems. The way w32start.ew works now is at best unpredictable, and it is central to the proper working of newUIObj().
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.
