Re: Namespace Proposal
Thanks Robert for giving us an opportunity to comment on your proposal.
I'm reading this as I'm having breakfast so please forgive me if my thoughts
aren't crystal clear yet.
>
> * A solution
>
> To alleviate this situation, I propose:
>
> 1. Let a local symbol override a global symbol with
> the same name for the duration of the scope
> of the local symbol. This is logical when you consider that
> private variables already override local and global symbols.
> This change alone would greatly reduce the number of conflicts.
This seems okay.
> 2. Allow multiple globals with the same name to
> coexist in a program. When you reference
> a global you can use its filename as a
> qualifier. e.g.
> graphics.text_color(RED)
One implication is that if the file name changes then I have to go an edit
my code to use the new file name. I might not have control of the filenames
either.
Another implication is that I can only refer to names declared by one file
but there might be more than one file included, just the extentions are
differrent.
Example:
The file "xyz.e" is ...
global constant aaa = 1
The file "xyz.ew" is ...
include xyz.e
global constant aaa = 2
The file "myprog.exw" is ...
include xyz.ew
constant xxx = xyz.aaa -- Which 'aaa' does this refer to?
Will constants, variables and routines all share the same namespace?
> Some have proposed a new syntax such as:
>
> include graphics.e as gr
>
> gr.text_color(RED)
>
> where you get to invent a new name, rather than
> rely on the filename. filename's aren't really nice to use,
> since on Windows they are case-insensitive.
> Also you might have graphics.e and graphics.ew in the
> same program. Or for that matter, graphics.xyz
This is my issue raised above.
> I think that introducing a new name would cause confusion.
> Everyone would make up his own new name,
> and people would have trouble reading each other's code.
Why would people have trouble? What is the difference in ...
include graphics.e
include mygraphics.e
a = text_color(RED)
b = my_text_color(RED)
and
include graphics.e as rds
include mygraphics.e as my
a = rds.text_color(RED)
b = my.text_color(RED)
Are you assuming that programmers aren't clever enough to understand this
syntax?
With the "as xxx" syntax, there is no reason that this cannot co-exist with
the "filename" syntax. Though I don't really recommend this because it could
lead to confusion or ambiguity.
Such that...
include graphics.e
include mygraphics.e as my
a = graphics.text_color(RED)
b = my.text_color(RED)
would be possible.
Another issue I have with just allowing filenames is that they tend to be
longer than necessary for coding, due to other reasons.
Example:
include w32infoattr.ew -- Constants for Win32lib GET/SETINFO message
result = Dispatch(mycntl, "GETINFO", {{w32infoattr.Maximum,
w32infoattr.Minimum}})
this can become rather wordy. how about this instead...
include w32infoattr.ew as prop -- Constants for Win32lib GET/SETINFO
message
result = Dispatch(mycntl, "GETINFO", {{prop.Maximum, prop.Minimum}})
> This syntax can be taken further, allowing variations on the include
> mechanism to achieve finer control over what symbols are
> part of what namespace. I think in a simple language like
> Euphoria, we don't need to create a highly-sophisticated
> namespace mechanism.
Why is "simple" and "highly-sophisticated" mutually exclusive?
Does this also mean that you regard Euphoria as a language only suitable for
simple programs? Meaning that if we have a complex program to write, we
should consider other languages.
Another alternative to both these suggestions is to let the include file
define its own namespace.
Example:
--Have this line near the top of graphics.e
namespace rds
--Have this line near the top of w32graphics.ew
namespace w32
then a user's program could have ...
include graphics.e
include w32graphics.e
a = rds.text_color(rds.RED)
b = w32.text_color(w32.RED)
The idea being that the "namespace" directive would create a namespace if it
didn't exist or use it if it had already been created, and then global names
would go in to that. You could have multiple "namespace" directives in the
same include file, naming different namespaces.
Eg:
namespace rdsC
global constant RED = 1
namespace rdsF
global function text_color(integer color)
------------
include graphics.e
a = rdsF.text_color(rdsC.RED)
Also, by using a namespace that already exists, it means that a related set
of files could all share the same namespace thus possibly increasing code
legibility.
include file.e
include get.e
a = rds.prompt_string(rds.current_dir())
rather than..
a = get.prompt_string(file.current_dir())
> I can see one special case where this proposal will break
> existing code. e.g.
>
> integer x
>
> include foo.e
> .......... global integer x
>
> x = 99 -- which x?
>
> Currently, the x declared in foo.e will be set to 99.
> Under the new proposal, the x at the top of the
> main file will be set. I believe this case is extremely rare.
You're probably right with this exception.
In summary, I believe that greater utility, at no significant cost, would be
provided if the namespace name and the file name were uncoupled. This could
be provided with either the "as name" syntax or the "namespace name" syntax.
------
Derek Parnell
Melbourne, Australia
"To finish a job quickly, go slower."
|
Not Categorized, Please Help
|
|
