1. Downside to namespacing
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.
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
On 23 Aug 2004, at 11:25, irv mullins wrote:
>
>
> 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.
>
> 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.
Won't work, i tried suggesting "with" years ago, along with "repeat-until" and
"goto" (which would have been a fine replacement for "exit", "repeat-until"
and "while-do"), string execution, and local includes. Well, it *will work*, but
RobC isn't interested in these things.
Kat
3. Re: Downside to namespacing
irv mullins wrote:
>
> 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.
>
> 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.
This might be a long thread 
As we all know already, Euphoria only reads in an "include" file once,
regardless of how many times it is mentioned in your source code. This
means that there is only one copy of the routines and variables in memory.
The trick of including identical (contents) files with different
namespaces is only workable in very few circumstances. In your case,
two copies might work, but soon as you need three or more it gets
just silly.
So, don't do it. It's not worth the effort.
Back to basics...
** Avoid global variables at all cost. Instead, access local variables
via global routines. Your "interface" should just consist of global
routines.
** Create multiple instances of objects (eg. ListViews) using Euphoria
sequence(s), and return to your application code a reference to the
instances, rather than direct access to it.
** All your lv library routines will access the ListView data (handles, ...)
by using the reference id, supplied to them from the application.
You will only need one lv.e file then, no matter how many ListViews you
create in your application.
--
Derek Parnell
Melbourne, Australia
4. Re: Downside to namespacing
Derek Parnell wrote:
>
> irv mullins wrote:
> >
> > 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.
> >
> > 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.
>
> This might be a long thread
>
> As we all know already, Euphoria only reads in an "include" file once,
> regardless of how many times it is mentioned in your source code. This
> means that there is only one copy of the routines and variables in memory.
> The trick of including identical (contents) files with different
> namespaces is only workable in very few circumstances. In your case,
> two copies might work, but soon as you need three or more it gets
> just silly.
>
> So, don't do it. It's not worth the effort.
>
> Back to basics...
>
> ** Avoid global variables at all cost. Instead, access local variables
> via global routines. Your "interface" should just consist of global
> routines.
> ** Create multiple instances of objects (eg. ListViews) using Euphoria
> sequence(s), and return to your application code a reference to the
> instances, rather than direct access to it.
> ** All your lv library routines will access the ListView data (handles, ...)
> by using the reference id, supplied to them from the application.
>
> You will only need one lv.e file then, no matter how many ListViews you
> create in your application.
Both approaches look like workarounds for a problem which could be solved
neatly and cleanly, if Euphoria didn't try to enforce what appears to be
a needless rule.
If a file is included multiple times without being namespaced, then there
should be only one copy loaded. If it is included twice with different
qualifiers, why should it not be included twice?
Irv
5. Re: Downside to namespacing
irv mullins wrote:
[snip]
>
> Both approaches look like workarounds for a problem which could be solved
> neatly and cleanly, if Euphoria didn't try to enforce what appears to be
> a needless rule.
>
> If a file is included multiple times without being namespaced, then there
> should be only one copy loaded. If it is included twice with different
> qualifiers, why should it not be included twice?
Oh, don't get me wrong. I'm with you on this one. I've been
advocating this concept from the early days of namespacing
suggestions. Namely ...
** Each unique namespace is a 'container'.
** A namespace may contain entries from multiple files.
** All files included into a given namespace are contained
by that namespace.
** Any given file is only present at most once in any namespace.
** To access globals in a namespace you must use the namespace
qualifier on your access expressions.
This would not have broken existing code, and it would have
helped you in your application. But RDS is never going to
implement this style of namespacing now, especially as it has
a different one.
However, having said that, I still think your approach to this
programming problem is flawed, regardless whether you are using
Euphoria or not. Do you really want multiple copies of your
routines and constants in RAM?
<soapbox>
We are doomed to work with the Euphoria we have, until such
time as an alternate supplier arrives. If you want to work
in Euphoria then you have to learn to use it as-is. RDS has
a long history of glacially slow improvements. Euphoria is
getting better, but its a bloody slow process. And all attempts to
improve the process are rejected; but that's their right, of course.
</soapbox>
--
Derek Parnell
Melbourne, Australia
