Re: Euphoria vs. other programming languages
- Posted by mattlewis (admin) Mar 10, 2009
- 1448 views
If an identifier appears at line x in file y, you now don't know at all in which line and which file it was defined. In 3.1, you know it comes from a previously parsed symbol.
A previously parsed symbol...from somewhere.
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.
CChris, in your own [preferred!] coding style, you had files that used variables in files that you never included in any way, shape or form, but required the file that included them to have defined the file. I seriously don't understand how you can claim to be interested in maintainability.
Could be anywhere, maybe without any reference to that file, or anything remotely like it. Granted, this is still possible (and is why I mentioned global scope), but less likely, and should at least give the coder a warning in 4.0.
Likewise, there is no way to determine easily where a public symbol is being seen. You have to follow all the chains of "public include" directives that start from the definition file to sort it out. In 3.1, a global symbol was seen from the point where it is defined onwards, period.
As opposed to wondering which files were included and were filling up the global namespace? At least there is a chain of public includes.
Do you mean that you don't know which files are in the source set? Come on, let's talk about real life.
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?
The point of a public symbol was for a library to expose its API this way, but still retain the ability to share other symbols amongst its files without exposing those by using the export scope. So you would assume that any source file that has included the library would be able to see all of the public symbols in that library. This seems extremely simple to me.
As an application author, your concern is that you're using the library in question. And it's very easy to do that by putting include the_library.e in the source file. As the library author, you know that any source file that includes your library will be able to see your public symbols.
If you're relying on globals simply being in the same folder, then you still have to worry about inclusion order (in 3.1).
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.
I agree, you are unable to comprehend it.
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.
In 4.0, a global symbol is further hidden if defined by an ancestor or sibling file. You need to add in extra include statements to see it. This has two drawbacks: 1/ vastly increasing the occcurrence of cyclic inclusion, which in turn require badly designed forward references to avoid errors; 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.
Yes, I left out the parsed before issue. But this is an important point, so thanks for bringing my attention to it. Strange order of inclusion issues can easily trip you up in 3.1, causing global symbols you were counting on not to be available. In 4.0, it's less important, though it opens some possibility of symbol clashes, which, BTW are easily resolvable, unlike the order of inclusion issues in 3.1.
In fact, in 4.0 you do not need to add an include statement to see the globals elsewhere. Please understand the topic before you fly off the handle.
- Please enlighten us as to a better forward reference design. I know that your proposal was discussed on the developers list, but the broader audience of the EuForum has not had the opportunity to review it.
- The re-usability of code is not reduced at all. You can still use this paradigm as before, using global symbols. It's still a broken way of doing things. You can get the same effect by exposing an API for the users of your library to use. This would be like requiring win32lib users to make their event handlers global, and to have win32lib call them directly.
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.
I've used Win32Lib with 4.0. So have others. Perhaps the example isn't as obvious as you think.
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().
Huh? He found some bugs in the implementation. Most of his findings have been fixed (still working on one). As I said, I've used win32lib with 4.0, and it works just fine. Please leave the FUD somewhere else.
Since you've yet to give any reasons why it's more difficult in 4.0 to determine scope and to find where symbols are defined than with 3.1, yes, I would like to hear more.
Simply _read_ the emails you reply to _before_ replying.
CChris, I have read them. So have others. We've all called BS. If you have anything new to say, then I'd be interested to hear it, but not your same, discredited arguments.
Matt
