1. RE: Downside to namespacing
- Posted by Mike <vulcan at win.co.nz>
Aug 23, 2004
-
Last edited Aug 24, 2004
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
2. RE: Downside to namespacing
- Posted by irv mullins <irvm at ellijay.com>
Aug 23, 2004
-
Last edited Aug 24, 2004
Mike wrote:
>
> 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.
You are correct, but only because that's the way Euphoria does things.
Looked at logically, if I take one file and copy it under a new name,
I now have two files, identical in every way except name. I can
include those two using different namespace qualifiers, and Euphoria
handles it with no problem. In other words, variables with identical names
are NOT the same variable, because they are prepended with the namespace
qualifier.... A:foo and B:foo, for example.
Now, the ONLY difference between reading in two identical files with
different names, and reading in one single file twice, prepending
each with a different qualifier, is that Euphoria refuses to do it!
That's all.
I'll respond to your other suggestion when I have time to actually
code it.
Irv
3. RE: Downside to namespacing
- Posted by irv mullins <irvm at ellijay.com>
Aug 23, 2004
-
Last edited Aug 24, 2004
Mike wrote:
> 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.
The first thing I see wrong with this idea is the additional code and bugs
which will be introduced. The second thing is the added layer of indirection,
which may make a difference when loading a large list into a listview, for
instance.
A third problem is going to be more complex calls. And I see no way to avoid
exporting
at least one thing: the handle to the listview itself. That is necessary if
*anything* is going to be done to the list. In addition, since listviews use
the M/V/C scheme, I would have to create a lookup table to associate the various
list stores, iterators, etc with the correct listview. All in all, it's way
easier to just copy and rename the one, simpler file.
Irv
