Re: Euphoria vs. other programming languages
- Posted by mattlewis (admin) Mar 12, 2009
- 1392 views
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.
No, I understand what you're doing. I'm saying you're doing it wrong. It's generally called dependency injection or possibly inversion of control.
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.
Yes, I am explicitly saying don't do this. It is really bad practice. There is a better way to get the same effect. See the links I provided above. I'll repeat: You're doing it wrong.
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.
Yes, something like that could work. But again, it's fragile. You've added another point of maintenance that may need to be changed. The intent of the coder is perfectly conveyed by standard include directives, even though you don't believe in them.
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.
and with terrible overhead, and multiplying the points to look at when the included library changes. Good job.
I'm not sure what you're referring to, but the best I can figure is the overhead in the parser. When files have properly declared their dependencies, it's not too bad. And well worth the effort for the application or library developer.
Yes, it was a good job. 
Matt
