Re: Namespaces (3)
- Posted by Irv <irv at ELLIJAY.COM> Oct 23, 2000
- 392 views
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