Re: Euphoria vs. other programming languages
- Posted by CChris Mar 12, 2009
- 1369 views
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.
The coding style should reflect, as much as possible, the intended code and data flow. So, if some structure fits the bill, it is more maintainable because it is understood more easily and is less likely to have bugs in the first place.
To be clear here (because I'm sure there are readers that aren't aware of what you're talking about), the 'structure' we're discussing is where there is a library that relies on the application using it to define certain globals, and then use those symbols.
Not true. What I describe is NOT a library, but rather a plugin, optional component, removable component, call it as you like. It is NOT the black box that a third party library ideally is.
Of course, if multiple symbols match, you're SOL, without modifying the library. This sort of requirement to modify 3rd party code was a big driver behind the scope and inclusion changes in 4.0.
And I've yet to hear anyone but you argue it should be considered a good practice to write a source file that uses other source files where it does not express that dependency as an include file. This would be like a user writing a library that depended upon win32lib, but never included win32lib.
When a subfile defines an API, there is nothing wrong with that. Your example shows your utter lack of grasping the subject, since it concerns a totally different issue.
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.
Another of your lies, Critic is right someimes.
The aim is to have parts of a program, either third party code or not, share symbols for others not to see, and also to allow symbols being seen everywhere even though they are not defined in the main source file.
Critic realized that we had a miscommunication. Please explain how I have lied, for apparently I have lied even to myself.
Even though you have my text right in front of your eyes, you make it say something completely different. I'm used to it, you've done it over and nauseatingly over before.
Saying something which is blatantly different from an easily available truth, for the some purpose of pretending to be right, i indeed lying. This doesn't eclude the fact that you may be lying to tyourself as well, I quite believe it actually. The two don't cancel out.
I can't see anything that I said above that contradicts this statement of yours. If you want the main file to do the 'heavy lifting' of including libraries, and avoid having to do that in other files that are part of the application, then simply use public include for your libraries, and have the sub files include main_app.ex, and you've got explicit inclusion there, without having to resort to globals.
which prevents reusing the subfiles with a parent of a different name, unless you edit them. Good job.
Really, most of your arguments come down to you being lazy, and believing that include statements are harmful to maintenance, not to mention too much effort.
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).
What is wrong with an inclusion order which shows in the simplest possible way which file uses which? Answer: i is too rigid and we have to deal with cyclic inclusions. That's where forward referencing helps on a case by xase basis.
The problem is that the inclusion order of a large set of source files can be a very fragile thing. And if some parts of your code rely on certain other parts, and if you have dependency cycles, then you've created additional maintenance to straighten out the dependency cycles.
Usually, cyclic dependenes arise because of only a few identifiers, less than a handful. In that case, an import <identifier> directive will indeed include the file, but (temporarily) hiding any unneeded public symbol. Parser won't choke on chicken and egg issues, and you still have mention of the file being relied upon. Much better conveying of the intent of the coder. [quote mattlewis]
One of the major benefits of the current design of forward referencing is that if you put include some_file.e in your code, then you can be assured that all symbols from some_file.e are available to the current file, without having to worry about dependency cycles. [/qote] and with terrible overhead, and multiplying the points to look at when the included library changes. Good job.
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.
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.
I cannot see any fact that support that claim, quite the contrary.
Yes, I pointed this out already above [that you can't see why it is true]. Consider, for instance, your preferred paradigm of having a library rely on symbols defined in another symbol, but not including that file. This requires that those symbols be created before that file is included and parsed. If that happens later, the code is broken. QED
That's why an import directive is useful for - more on this later.
- 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.
You limit yourself to the library - main app paradigm. It is certainly not the only possible one for larger apps.
I'm not sure what you mean here. But I was referring, generally, to the practice of using third party code in some other piece of code. The code in question could be designed to be a library itself, so that users of the new library would be using libraries that use libraries, and possibly multiple such libraries.
But the important point is that to the end user, the library is a black box. He includes the library into his project, and uses the API provided by the author of the library. And here's the important part: the library works like it's supposed to, no matter what other libraries are used, or in which order they are included into the project. You've chosen a particularly problematic way to do this, since it's fragile to things like namespace conflicts, and doesn't necessarily play nicely with other libraries.
Matt
