OpenEuphoria

Re: Packages

• Posted by CChris <christian.cuvier at agricult?re.go?v.fr> Aug 07, 2007
• 530 views

Jason Gade wrote:
> 
> CChris wrote:
> > 
> > Jason Gade wrote:
> > > 
> > > CChris wrote:
> > > > 
> > > > Jason Gade wrote:
> > > > > 
> > > > > CChris wrote:
> > > > > > 
> > > > > > jacques deschênes wrote:
> > > > > > > 
> > > > > > > Your system is too complex, it add a lot of new keywords. Why make
> > > > > > > it
> > complex</font></i>
> > > > > > > when one can make simple.
> > > > > > 
> > > > > > Because simple systems won't work.
> > > > > > They will create issues of their own, out of short-sightedness.
> > > > > 
> > > > > Surely you're joking?
> > > > > 
> > > > > And in a different thread:
> > > > > 
> > > > > > We seem to live on different planets.
> > > > > 
> > > > > True.
> > > > > 
> > > > 
> > > > I agree. But some aspect of your planet are causing serious trouble to
> > > > my
> coding.</font></i>
> > > > 
> > > > > Here's my proposal, one new keyword, but I don't know if it is
> > > > > possible:
> > > > > import <lib> [as <namespace>]
> > > > > 
> > > > > This works just like include but globals included or imported by
> > > > > imported
> files</font></i>
> > > > > are no longer visible. It acts as a block to global namespace
> > > > > pollution.
> > > > > 
> > > > > Basically it only imports symbols defined in <lib>, not symbols
> > > > > defined in
> <lib>'s</font></i>
> > > > > includes or imported files. Those go... somewhere else.
> > > > > 
> > > > 
> > > > in my_app.exw:
> > > > import my_lib.e
> > > > 
> > > > in my_lib.e
> > > > include get.e
> > > > 
> > > > Can my_app.exw access routines in get.e?
> > > > 
> > > > If so:
> > > > 
> > > > in my_lib.e:
> > > > global function my_func()
> > > > import my_utils.e
> > > > 
> > > > in my_utils.e:
> > > > x=my_func()
> > > > 
> > > > 1/ Is the above call valid?
> > > 
> > > On further consideration this should break. Include should treat files as
> > > text,
> > > import should treat files as modules and work one way.
> > > 
> > 
> > It shouldn't. Submodules need - most of the time - to call some central
> > routine
> > in the file that includes them. It really would be a terribly useless,
> > harmful
> > regression if this started to no longer work.
> 
> Then use include. Don't use import. Isn't that what you say to others when you
> propose a change? Don't use it if you don't like it?
> 

Of course I can. Problems arise when others start using import, because the way
"you" include files has consequences on how "my" globals are seen. goto is pretty
harmless in regard, because, if others use it, it won't impact the code I write.
The quotes are meant to show that use of you or my hasn't anything personal
attached to it.

> > 
> > > > 2/ What happens if my_app.exw also defines a global my_func(), and some
> > > > other
> > > > file calls that global?
> > > 
> > > It depends if the other files are linked with include or import.
> > > 
> > 
> > Oh, how is this related to goto? And who is Shirley?
> 
> Because if this isn't spaghetti code then I don't know what is.
> 
> > 
> > Don't you think your approach will make placement of routines even more a
> > nightmare
> > than it currently is? Not only you have to deal with define_before_use, but
> > now you'd add define_before_import or somesuch. Cant believe it.
> > 
> > CChris
> No idea what this means.
> 

When you use several files in a library, you tend to put routines into them
according to some loose theme classification. That's why you create several
files, right?
The define_before_use rule prevents to do this sometimes, and leads to pretty
unnatural routine placements and a large amount of time figuring out where
exactly in the main file to put some include statement.
In the proposal which you have stated so far (particularly in question 1/), you
are adding extra constraints on this already delicate issue. This is neither
simple nor elegant, but torture.

In contrast, my solution provides more freedom in this respect, not less.
CChris

> --
> "Any programming problem can be solved by adding a level of indirection."
> --anonymous
> "Any performance problem can be solved by removing a level of indirection."
> --M. Haertel
> "Premature optimization is the root of all evil in programming."
> --C.A.R. Hoare
> j.