1. Re: Namespaces (3)
All of this is a bit unfair, I'm thinking, since it isn't Dave Cuny's fault
that Euphoria has such an awkward sequence indexing scheme.
However, the ball's in his court, for the moment.
Dave's namespacing solution, it appears, will solve only a portion of the
namespacing problem. How significant a portion varies with the individual.
If yuu use a lot of "includes" written by other people,
import <file> as <namespace>
will prevent collisions, and so be useful.
On the other hand, it does little to alleviate the "internal" namespacing
problem, the one that plagues programmers daily. I refer to this example:
-- addrbook.pi
NAME = 1
ADDR = 2
CITY = 3
record = {NAME,ADDR,CITY}
|==========================================|
| Py (c) David Cuny |
| Euphoria (c) Rapid Development Software |
| Dictionary code (c) Jiri Babor |
+==========================================+
type 'bye' to exit
Py > import "addrbook.pi" as customer
Py > customer.record[NAME] = "Joe" -- FAILS
customer.record[NAME] = "Joe"
NAME is not declared
File: <stdio>, Line Number 1
Py > customer.record[customer.NAME] = "Joe" -- SUCCEEDS
Py> customer.record[customer.ADDR] = "145 Walnut Ave" -- SUCCEEDS
Py > ? customer.record
{"Joe","145 Walnut Ave",3}
Py > ? customer.record[customer.NAME] -- name must be fully qualified
"Joe"
=============
So, we're right back where we started. If we have to fully qualify the
field names within the [], we might just as well have declared the indexing
constants as in the past, prepended with the filename and an underscore.
constant
customer_NAME = 1,
customer_ADDR = 2,....
What needs to happen, I believe, is for namespacing to expand names within a
given block of code. Perhaps this is familiar (from Pascal)
with customer .record do
NAME = "Joe"
ADDR = "123 Walnut Ave"
....
Since, in the last few programs I've written in Euphoria, I didn't have need of
anyone else's code, the namespacing solution as it now stands would have
saved me exactly 0% of my time.
OTOH, on a program I wrote last year, having some shorthand such as that shown
above could have saved a significant amount of time.
Regards,
Irv
