OpenEuphoria

RE: Downside to namespacing

• Posted by Mike <vulcan at win.co.nz> Aug 23, 2004
• 513 views

Irv,

I think a possible solution could be to do with the programming 
approach.

> posted by: irv mullins <irvm at ellijay.com>
> 
> I have a program which 'includes' a module. Let's call it lv.e.
> The module handles listviews, exporting only the variables 
> necessary to add, scroll, and respond to list events. 

(please correct me if I'm wrong) but if lv.e handles a single listview 
(not listviews) and those exported variables are intrinsic to it's 
operation then the module can only ever support that one object - which 
is why you currently need 2 modules to manage 2 listviews.

My suggestion is to drop all exported variables and provide an interface 
of routines that allow multiple object functionality. Now, I have not 
seen the module to guage an idea of how complicated this might be but in 
the large programs I have (am) working on it hasn't taken that much 
extra effort.

I hope this helps. 

Mike

PS: This idea squashes your namespace problem.

PPS: Flames are welcome 


> I want to use two listviews in my program. Both use the routines in 
> lv.e.
> I can't include the lv module twice, with different namespace 
> qualifiers,
> but I can copy the module under a new name, and then include them with 
> qualifiers:
> 
> include lv1.e as view1
> include lv2.e as view2
> 
> So far so good (well, not really, but it works).
> 
> Now, when I want to refer to the variables in view1, for example, 
> I must write:
> 
>
> view1:add_row(view1:store,view1:iter,view1:this,view1:that,view1:the_other....)
> 
> 
> The view, as well as each variable must be individually qualified. This 
> is 
> a simple example, I'm sure you can think of others where the qualifying 
> would get even more complex. Why can't we say:
> 
> with view1 do
>   add_row(store,iter,this,that,the_other)
> end with
> 
> Doesn't that make more sense?
> Perhaps someone can see an even better way of doing this.
> 
> Irv