Re: Named Scopes (was Re: Feature requests for Eu 2.5.)
> From: Pete Lomax <petelomax at blueyonder.co.uk>
> Subject: Named Scopes (was Re: Feature requests for Eu 2.5.)
>
>
> I decided to post this separate from my reply to CC, to stop it
> getting buried.
>
>
> I do like the idea of named scopes. My view is something like:
>
> scope scopename
> <variables, constants, routines, and include files>
> end scope scopename
>
> <illegal to reference anything in scopename here>
>
> procedure xxxx()
> use scopename
> ... <can use items from scopename here>
> end procedure
>
> <illegal to reference anything in scopename here>
>
> use scopename
> ...
> <can use items from scopename here>
> ...
> <end of file>
>
Hi, I'm back.
This is the way Sheerpower handles private vars, and you can indeed
emulate a host of features (static or shared vars, nested routines etc)
with this.
I'm not sure that it is the better way to do, since it may obscure the
code readibility more, IMO, than separate features with specific use for
each. Having said that, I'd feel much more comfortable with these named
scopes than now, clearly.
> scopes may optionally be global.
> If the global keyword is used anywhere inside a named scope, it makes
> the definition available throughout the scope (ie to any includes
> inside the scope), but not global outside the scope.
>
> The XXX has not been declared error should probably be followed with a
> message XXXX is however defined in named scope x, similar to the
> namespace qualifier is required message.
>
> When use scopename is coded, the <toplevel> local symbols in it can be
> referenced, even if it the scope is defined in another file.
>
> I can't see any obvious difficulty nesting scopes, of course a use
> outerscope statement does not grant access to innerscope.
>
> It should however be possible to code
>
> use outerscope
> use innerscope
>
> but only if innerscope is declared global.
>
>
> Pete
Btw, just a short answer for Bernie:
I'm not a good C coder, and I don't feel at ease with it (C++ is
better). Much more used to Pascal, and I can't tell you why I find it so
hard to read C code, given this.
When I discovered Eu, I was very impressed becaue some key aspects of
programming with it were more in line with what I'd expect from a
programming language. That's why I did not just leave and move on as
many did.
I'd add that buying a piece of software because you want to improve it
sounds like strange logic to me. This is the reason why I'll probably
stay around the OE team. I'm more on the test/docs side, but contributed
a few things about language design already.
As jbrown emphasized, OE forks from Eu, and is not a clone or
concurrent to it. Since its source will be public, RC may get the help
you mentioned from the real thing, when it flies.
Hope I made my point clearer for you.
CChris
|
Not Categorized, Please Help
|
|
