Re: Euphoria vs. other programming languages
- Posted by jimcbrown (admin) Mar 10, 2009
- 1393 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.
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)
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?
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.
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.
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.
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.
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.
