1. Downside to namespacing
- Posted by irv mullins <irvm at ellijay.com> Aug 23, 2004
- 426 views
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
- Posted by "Kat" <gertie at visionsix.com> Aug 23, 2004
- 424 views
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
- Posted by Derek Parnell <ddparnell at bigpond.com> Aug 24, 2004
- 397 views
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
- Posted by irv mullins <irvm at ellijay.com> Aug 24, 2004
- 426 views
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
- Posted by Derek Parnell <ddparnell at bigpond.com> Aug 24, 2004
- 418 views
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