Re: Namespace Proposal
Excellent, namespaces are coming :)
> Here's what I'm planning to do in 2.3 about
> the so called "namespace problem".
>
> * First, what is the problem?
>
> In Euphoria, as in all programming languages,
> naming conflicts can occur. To reduce these conflicts,
> there are mechanisms to reduce the scope of names.
> For example, in Euphoria we basically have three
> different scopes for user-defined names:
>
> private - visible only within a routine
>
> local - visible only within a file (after the point of declaration)
>
> global - visible everywhere (after the point of declaration)
>
> To keep things simple, we'll ignore keywords, built-in routines,
> and loop variables.
>
> This lets you for example, have a private variable x
> in one routine, and a private variable x in another
> routine, and the two are understood to be different variables.
> There is no naming conflict. You can also have a private
> variable x, and a global or local variable x.
> No problem.
>
> The main problems that have occurred have been with
> global symbols. Because they are visible everywhere
> (after they are declared), they tend to cause conflicts.
>
> For example, if I add some new global routines or variables
> to the standard Euphoria includes, it is very likely that I
> will break someone's code, since someone is likely to have
> already declared the same symbol in their program. For example,
> if I were to add an abs() function to misc.e, it would conflict
> with similar abs() functions declared globally and locally in
> many people's code.
>
> Similarly, if you try to use two large libraries (include files)
> written by different people, there's a chance that a global
> symbol in one will conflict with a global or local symbol
> in the other. If you have the source, you can edit one of the
> includes, but when the author comes out with a new version,
> you'd have to re-edit it each time. Not very convenient.
>
> * 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.
Sounds good, better make it a warning though, could lead to some very
nasty bugs...
> 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)
>
> 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
>
> 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.
>
> 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.
How about some sort of way of defining the namespace with in the file, like:
namespace <name>
end namespace
or maybe something more along the lines of the "with" statement
(effects the whole file). Also I do like the:
include <file> as <name>
Maybe that could also be added, it would override the namespace set in
the file or could be used for files that don't have namespaces...
I really don't like the idea of having the namespace set by the
filename of the include, it's quite possible that 2 files with exactly
the same name get included, they could be in different directories (I
tend to do that, have files spread out over lots of directories to help
organize things better).
> 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.
>
> Any suggestions?
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
Looking forward to the new version :)
Thomas Parslow (PatRat) ICQ #:26359483
Rat Software
http://www.rat-software.com/
Please leave quoted text in place when replying
|
Not Categorized, Please Help
|
|
