Re: Euphoria Standard Library on UBoard
Robert Craig wrote:
> Derek Parnell wrote:
> > Robert, I'm going to sound rude here, so please forgive me. But are you just
> > not listening
> > to us?????? A number of times you have been told about the problem with
> > namespaces.
> >
> > I repeat it yet again.
>
> You and Matt seem to be talking about the same problem and same
> proposed solution. As you might recall, I was initially enthusiastic
> about the solution, but later when it came time to actually implement
> it, I realized that there were a couple of negative aspects that I hadn't
> really thought of when it was first discussed, so I put it aside.
>
> On January 31, 2005 I wrote:
> >
> > 1. The change was going to add complexity and subtlety to
> > namespace rules that many people already had trouble
> > remembering.
> >
> > 2. After porting thousands of lines of C code to Euphoria
> > (i.e. the front-end), I had a couple of nasty cases where I
> > accidentally declared a global variable in two different files.
> > No error message was given, yet I was updating two different
> > variables, not one. It took a while to figure out what was
> > happening. Since the proposed change to the namespace rules
> > would increase the chances of this sort of bug going
> > undetected, I considered that to be a negative thing,
> > that would partially offset the positive effect of fewer
> > spurious error reports.
>
> For the time being, I'd like to leave the namespace issue on the back burner,
> until we gather more information from people reporting actual, real-life
> (as opposed to imagined or theoretical) namespace problems. Maybe later
> we can take another stab at it.
>
> For some reason this feature has generated far more discussion than
> it deserves, given the small percentage of users who actually
> encounter symbol conflict problems.
>
> Before implementing this feature, there was a full discussion
> on this list of how it should work. I believe Derek, Matt, Irv
> and many others were involved. I proceeded under the assumption
> that, while they may have preferred other designs, they did not
> see any obvious defects in this design.
What to me personally, I did not need and do not need the namespace
feature at all, the v2.2 had the perfect scope design for the personal
private programming. I never use these 'as' prefixes in my programs
and hate the colons and extra dots in the program text.
The main disadvantage of v2.3+ is ambiguous sense of the
current (i.e. local) global names - they simultaneously are
local for the current file and can override the other same global
names (the superglobal concept of the local names, so to say).
I do not see a way to return back to the excellent v2.2 globals
without a new kind of names - let us name them "custom" names.
A special kind of names for the library writers and users.
A custom name may be just the *current* global
name or any more sophisticated thing.
The scope rules for these customs may be complicated
enought to correct some program projects which need
this correction with the namespace prefixes, or
for different OOP features. Custom is custom.
Scope is complicated, rules are whimsical.
Alise, Bob, Carl and others can write their
crazy projects and ask RobC for any new custom.
The new "global" is just that old good "global" of v2.2 and
older versions.
Only private names can override this new/old global names.
Global is global - scope is linear and monolithic from
the point of declaration. Global does not require a prefix.
Rules are simplest.
Say,
custom integer A
custom function abba(integer s)
return s*s*s
end function
global constant TRUE = 1,
FALSE = 0
atom Z
Z = 3.33
include lib.e as her::
her::Z = 5.55 -- to use some custom atom Z from lib.e by Mister_Y
'as' - new keyword to define prefix plus a delimiter - colon,
dot, two colons and so on, maybe, I am not sure.
Just my $0.02. I can be happy without all these things.
Good Luck!
Regards,
Igor Kachan
kinz at peterlink.ru
|
Not Categorized, Please Help
|
|
