OpenEuphoria

2. Re: Global = root of all evil

• Posted by Derek Parnell <ddparnell at bigpond.com> Nov 02, 2006
• 590 views

Euman wrote:
> 
> Hi all,
> 
> Global vars, funcs, procs, etc.. root of all evil??
>  
> more so in C but in Euphoria as well..
> 
> Any takers??
> 
> personally I'm making sure my habits of using global's
> extinct..for the most part..

Agreed. The more global items you have the more dependancies you create between
files. And the more dependancies the harder it is to change things without
upsetting something (or someone) else.

A good rule of thumb (and this has been around since the 1970s) is eliminate
every instance of module coupling, except where you absolutely must have for
performance reasons (and that is almost never).

This doesn't really apply to global constants though.

-- 
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell

4. Re: Global = root of all evil

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Nov 02, 2006
• 614 views

On Wed, 01 Nov 2006 17:53:37 -0500, Euman <Euman at triad.rr.com> wrote:

>Hi all,
>
>Global vars, funcs, procs, etc.. root of all evil??
> 
>more so in C but in Euphoria as well..
>
>Any takers??
>
>personally I'm making sure my habits of using global's
>extinct..for the most part..

It is not a bad idea to perform a global search for "global" as part
of source code cleanup. Global constants and routines are a bit of a
necessity. If your results are something like:

eaclip.ew:17 global function copyTextToClipboard(sequence lines)
eaclip.ew:66 global function getTextFromClipboard()
eaclip.ew:116 global function isClip()

Then you can be pretty sure it will not cause you much grief, even:

global integer cbX, cbY
global procedure ctrlBracket(integer direction)
--
-- process ctrl [ and ctrl ].
-- jump to matching [end] procedure/function/type/for/while;
-- cycle fwd/back through if/{elsif}/else/endif;
-- jump to matching [,], (,), {,}.
--
-- direction is -1 for backward, +1 for normal forward, or 
-- 0 for forward skipping elsif/else. (fold handling)
--
-- Result in cbX, cbY
    cbX=CursorX
    cbY=CursorY

is not too bad, as cbX, cbY are only meaningful after a call to
ctrlBracket, and hence it does not matter if you overwrite them in
some other random place, whereas:

easynld.e:9 global sequence Extensions,     -- eg {"e","ex","exw"}
easynld.e:12 global integer newSyntax        -- ExtensionNo, or 1=none
easynld.e:15 global sequence SynNames,       -- eg "Euphoria"
easynld.e:30 global integer MAXnColours
easynld.e:56 global sequence wordChar    -- set by easynld.e
easynld.e:59 global sequence standardColourNames,standardColours
easynld.e:96 global sequence comment -- eg "--"  -- set by changeTo()
easynld.e:97 global sequence blockComment        -- ""
easynld.e:98 global sequence ColourTab           -- ""
easynld.e:99 global sequence StyleTab            -- ""
easynld.e:103 global sequence charMap     -- set by changeTo()
easynld.e:105 global sequence urlChar     -- all are TokenChar
easynld.e:706 global procedure initSyn()
easynld.e:773 global sequence sampleBrush,
easynld.e:782 global atom backBrush
easynld.e:784 global atom wwrapPen
easynld.e:786 global function reBrush(sequence cnew, sequence cold)
}}}
<eucode>
Then it is immediately obvious there is much more scope for trashing
something vital elsewhere and maybe you should rethink that code.
The routine interfaces can also be far harder, as you may be expected
to set a global variable correctly before calling (actually also true
of CtrlBracket above).

Ensuring that any global variables you need have well-thought-out
names that are unlikely to be accidentally re-used elsewhere is one
way of reducing the risks.

One half-baked idea I have is 'global-constant-local-variable's, ie
you can legally modify them within the source they are defined, but
get compiler errors if attempting to modify them anywhere else.
Not exactly sure how to specify that though, how does:
}}}
<eucode> 
global constant udt myTable, myList

(where udt could be integer, boolean, seq8 etc) sound? It would not be
legacy compatible though, currently the "global constant udt" part 
would define a new variable even if a valid [global] type udt exists, 
and any similar legacy code would cause a compile error when run on a
newer version of Eu. A more compatible idea is:

glocal udt myTable,myList

which gets my vote, but "glocal" is admittedly a bit odd. Of course
you can stick with the local var + global get()[/set()] method.

One last thing I will say is that forward routine references can cause
headaches enough, imo allowing forward references to [global]
constants and variables would really damage the elegance of the
language (and probably treble compile times). I assume you had an
"episode" which triggered this thread, care to share?

Regards,
Pete

6. Re: Global = root of all evil

• Posted by ags <eu at 531pi.co.nz> Nov 02, 2006
• 599 views

Pete Lomax wrote:
> 
> On Wed, 01 Nov 2006 20:38:35 -0800, ags <guest at RapidEuphoria.com>
> wrote:
> 
> >}}}
<eucode>
> >else
> >    greet() -- default
> ></eucode>
{{{

> IMO, you really don't want to do that. If there is more than one 
> routine named "greet()", you must be specific. Having a 'default' 
> version of greet() (presumably the one from the include w/o "as") 
> which the compiler just assumes you mean if you forget a qualifier 
> could be /really/ annoying. 

Yep, a hasty example, lacking proper documentation   The above greet() would
actually be in the source file, not the include file.

> PS eg fr:f(fr:x(),y(),fr:z())  should flag the y() missing namespace,
> obviously in real code that missing 'fr:' could be real hard to spot
> and/or lead to a very subtle and very hard to reproduce bug.

I think the error message would be something like 'call to undefined function
y()', ie any routine without a namespace is assumed to be in the 'main' source
file, as you would expect.  I wrote something on the wiki a while ago suggesting
a 'without globals' that would not search for y() (without a qualifier) in any
include files, but that might get confusing.

Having said all that, I don't think I'd actually like to see these things
implemented in Euphoria   I think Euman's approach is probably better, just
get include/library/wrapper makers to stop making things global "because it's
easy".  It's akin to making every variable of type 'object'... keep data local
and use exported methods to inspect or modify it.

(goes off to look at own code ;)

Gary

8. Re: Global = root of all evil

• Posted by Bernie Ryan <xotron at bluefrog.com> Nov 02, 2006
• 589 views

Global use in Euphoria is necessary because the name-space implementation
is limited.

I would suggest that all of you users that have been demanding that
Euphoria become open source get to work and rewrite Euphoria's
name-spaces just the way that you have been harping at Rob to fix
it.

That does not mean to say to Rob this is how to do it but to come up
with code that works the way that you said it should.
   
Bernie

My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API 

Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan

10. Re: Global = root of all evil

• Posted by cchris005 at fastmail.fm Nov 02, 2006
• 600 views

Daryl Border already oposted code in the Archive to have the inclde
system behave in a more functional way; it modifies only the front end,
so let's  start with this.
My own preference is for full modularity, with a client list for each
symbol that needs be visible outside its definition file, like in
Eiffel.


CChris

On Thu, 02 Nov 2006 08:30:21 -0800, EUforum at topica.com said:
> Subject: Re: Global = root of all evil
> 
> 
> posted by: Bernie Ryan <xotron at bluefrog.com>
> 
> 
> Global use in Euphoria is necessary because the name-space implementation
> is limited.
> 
> I would suggest that all of you users that have been demanding that
> Euphoria become open source get to work and rewrite Euphoria's
> name-spaces just the way that you have been harping at Rob to fix
> it.
> 
> That does not mean to say to Rob this is how to do it but to come up
> with code that works the way that you said it should.
>    
> Bernie
> 
> My files in archive:
> WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API 
> 
> Can be downloaded here:
>
> http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
> 
> 
> ------------------------------

-- 
  
  cchris005 at fastmail.fm

-- 
http://www.fastmail.fm - Access your email from home and the web

12. Re: Global = root of all evil

• Posted by Mario Steele <eumario at trilake.net> Nov 03, 2006
• 604 views

Al Getz wrote:
> 
> Hi there,
> 
> I realized these kinds of problems long ago, that's why i came up
> with WinClass.  You have to call global functions somehow, and using
> a class sort of methodology seems to be a good idea, as many things
> have common names yet have to be catagorized separately.
> If anyone has a better idea i would sure like to hear it 
> 
> Example:
> 
> You have two button objects, ButtonTypeA and ButtonTypeB.
> There are some similarities between the two but many differences too,
> which makes using a flag based system a little difficult, both for you
> AND the person that is going to create these objects.  A good
> solution seems to be:
> 
>   constant Button1=BTypeA:Create(params)
>   constant Button2=BTypeB:Create(params)
> 
> The values for params are kept in the file with the code for that
> button type and are documented carefully:
> 
>   Create(
>     integer style, --style=1 for raised, 0 for recessed
>     sequence name, --button text, name="MyButton" for example
>     atom color     --face color, color=#808000 for example
>     )
> 
>   Create(
>     integer style,  --style=1 for raised, 0 for recessed
>     sequence name,  --button text, name="MyButton" for example
>     atom facecolor, --face color, color=#808000 for example
>     atom textcolor  --textcolor=#FFFFFF for example
>     )
> 
> As soon as the user looks at the file they have a very good idea
> how to create that object.
> Also, because of the coding format it makes it fast to add features
> to an existing 'class'.  The underlying format is pretty much the
> language itself, so there are less ideals to have to push on the
> programmer...
> 
>   Create(
>     integer style,  --style=1 for raised, 0 for recessed
>     sequence name,  --button text, name="MyButton" for example
>     atom facecolor, --face color, color=#808000 for example
>     atom textcolor, --textcolor=#FFFFFF for example
>     integer advancedstyle  --advancedstyle=PUSHON_PUSHOFF or PUSHBUTTON
>     )
> 
> Once the ability to actually include an include file a second (or more)
> time(s) gets into the language it will be even easier to create a class
> and then create objects of that class...as you can now do with C++.

All I have to say Al, is that this is Object Oriented Programming, and this is
what I love about Ruby, with it's ease of use for Specifications of Class
Objects.  You can have the same Function on 2 different classes, same exact name,
but does two entirely different things.  If something like this was to occur,
there would be no need to worry about polluting the Global Namespace, no need to
worry about "fixing" the namespace problem with Euphoria itself.

And as much as people here have been harping about the idea, that "Oh well, if
you incorperate Object Oriented Programming into Euphoria, then your going to
have to use it."  I only have one thing to say.  If I want to use Procedual type
programming in Ruby, it's perfectly legal to do so.  I don't have to use the
Object Oriented programming styles of Ruby, but I choose to do so, cause that
saves 100 times effort on creating libraries, with conflicting namespaces. 
Something, I'm sure Euphoria could benifit from.

Mario Steele
http://enchantedblade.trilake.net
Attaining World Dominiation, one byte at a time...

14. Re: Global = root of all evil

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Nov 03, 2006
• 584 views
• Last edited Nov 04, 2006

On Thu, 02 Nov 2006 06:41:32 -0800, ags <guest at RapidEuphoria.com>
wrote:

>I think the error message would be something like 'call to undefined 
>function y()', ie any routine without a namespace is assumed to be in 
>the 'main' source file, as you would expect.
My apologies, I thought I was talking to someone who had a clue.
<cue flame war; trust me I'll dig my heels in to get my point across
and am unlikely to pull many punches...>

DUHH! we're talking about MULTIPLE y()! The WHOLE point was that it
should NOT */ASSUME/* a specific y(): How, in god's shit, does:
"eg fr:f(fr:x(),y(),fr:z())  should flag the y() missing namespace,"
NOT make that clear? Did in any bizzarre sense you imagine there was
NO included fr:y() or something?

Did in any bizzarre sense you imagine that I felt it would be /RIGHT/
to /ASSUME/ the local y()?

I can tell this is going to be a serious challenge if I still have not
made this point crystal clear... Onwards, anyway:

>>presumably the one from the include w/o "as"
>The above greet() would be in the source file, not the include file.
Ugh, this is the horrid bit squared. While I am aware that this needs
some very careful thought, particularly allowing existing libs to work
as-is, I firmly believe that eg:

include win32lib.ew
function create()

/SHOULD/ trigger an error (because it is a redefinition of a direct
include). Otoh, two sub/third-party-"components" both defining eg
abs() should not be a problem (and each use "their own").

I'm not sure how many 'old hands' would agree with me.

btw, no disrespect intended, of the undue variety anyway,
Pete
PS I am want to be very aggressive on these points; don't bother
taking it /too/ personally, instead try make me look stupid using
logic .
PPS Also I would be quite keen to discuss this amicably, and would
try, but kind of accept it is not really my style  I'll try tho.

16. Re: Global = root of all evil

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Nov 04, 2006
• 579 views

On Fri, 03 Nov 2006 18:15:55 -0800, Derek Parnell
<guest at RapidEuphoria.com> wrote:

>Pete Lomax wrote:
>
>> PS eg fr:f(fr:x(),y(),fr:z())  should flag the y() missing namespace,
>> obviously in real code that missing 'fr:' could be real hard to spot
>> and/or lead to a very subtle and very hard to reproduce bug.
>
>If we had the situation where every name collision had to be 
>disambiguated using namespace ids, and if one wanted to refer to a 
>'y()' routine that was local to the current file, how would one 
>indicate that? I mean, is it possible that the current file can have a 
>predefined namespace identifier ... ?
>
>   fr:f( fr:x(), this:y(), fr:z() )

Easy, in main.e:

include main.e as this

Regards,
Pete
PS:Forcing errors on local y() adds compile overhead, in checking for 
global-namespace-qualified-clashes, but then again the purist in me 
believes you should NEVER use namespaces unless faced with an 
otherwise unavoidable third-party clash.

18. Re: Global = root of all evil

• Posted by cchris005 at fastmail.fm Nov 04, 2006
• 589 views
• Last edited Nov 05, 2006

> Subject: Re: Global = root of all evil
>
>
>
>
> On Thu, 02 Nov 2006 06:41:32 -0800, ags <guest at RapidEuphoria.com>
> wrote:
>
> >I think the error message would be something like 'call to undefined
> >function y()', ie any routine without a namespace is assumed to be in=

> >the 'main' source file, as you would expect.
> My apologies, I thought I was talking to someone who had a clue.
> <cue flame war; trust me I'll dig my heels in to get my point across
> and am unlikely to pull many punches...>
>
> DUHH! we're talking about MULTIPLE y()! The WHOLE point was that it
> should NOT */ASSUME/* a specific y(): How, in god's shit, does:
> "eg fr:f(fr:x(),y(),fr:z())  should flag the y() missing namespace,"
> NOT make that clear? Did in any bizzarre sense you imagine there was
> NO included fr:y() or something?
>
> Did in any bizzarre sense you imagine that I felt it would be /RIGHT/
> to /ASSUME/ the local y()?
>

Obviously it is right.
When you call a global from your own code, you may or may not expect it
to be redefined. Eu should allow you, the coder, to decide. I'd advocate
the following extra keyzords
1/ generic: this would replace "global" zhen the coder allows
redefinition of the symbol he created.
2/ restricted: this symbol is not to be seen outside the current file
and the files it includes;
3/ undefine: this is a request for the given outside symbol not to get
in the way inside the current filem and any zhich would include it.

At any rate, if the intention of the coder is obvious, he must be able
to state it in a way obvious to readers of the code, /without
restricting/ much what he's able to code. The latter is perhaps why Eu
is so little known after 13 years of being around.

</snip>

> I firmly believe that eg:
> }}}
<eucode>
> include win32lib.ew
> function create()
> </eucode>
{{{

> /SHOULD/ trigger an error (because it is a redefinition of a direct
> include). Otoh, two sub/third-party-"components" both defining eg
> abs() should not be a problem (and each use "their own").
>

One should be able to define any local symbol without getting any error,
except when redefining inside the same file. And yet, using namespace
blocks (your idea a while ago_ should allow to override this. So, I'd
say a flat no to any error here. Optionally a zrning, asuming it could
be of any use.

CChris
--
=20=20
  cchris005 at fastmail.fm

--
http://www.fastmail.fm - Same, same, but different=85

20. Re: Global = root of all evil

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Nov 05, 2006
• 589 views

On Sat, 04 Nov 2006 05:27:32 -0800, Derek Parnell
<guest at RapidEuphoria.com> wrote:

>> >Pete Lomax wrote:
>> >> PS eg fr:f(fr:x(),y(),fr:z())  should flag the y() missing namespace,
>> >   fr:f( fr:x(), this:y(), fr:z() )

>Just to clarify, are you saying that for code to ensure that 
>references to identifiers in its own file are unambiguous, that a file 
>must include itself with a namespace id and use that namespace in the 
>references. 
Correct, if there is a clash.
This is/was an "aggressive" response to "Global = root of all evil".

<snip>
>one would always like local indentifiers to be unambiguous
<snip>
Agreed. It dawns on me that playing devils advocate just failed 
Where I really fell down on this thread is the argument that "globals
are the root of all evil" vs "too painful to enforce them properly".
I'll back down now, if that's ok, in truth I'm fairly happy with the
way things are.

I guess I was trying to say something along the lines of "you can't
really fix these things", but the moment's passed.

>What are you thoughts regarding the idea of using namespaces to prevent
>potential clashes?
>
>And what about using them as a form of documentation for code readers?
Yep, you win, sound uses both! )

Regards,
Pete

PS: I believe I owe an apology here, particularly to ags. It was a
complete over-reaction, no offense meant. Sorry if any taken.

22. Re: Global = root of all evil

• Posted by Chris Bensler <bensler at nt.net> Nov 06, 2006
• 590 views

Eu needs 2 things ot deal with global contamination.
1. more robust namespacing capabilties.
2. more robust include namespacing.

Both of these issues have been beaten to death.
IMO the best solution for namespacing is to allow arbitrary, top-level code
blocks to be namespaced. This still creates global contamination via the
namespaces themselves though. The namespaces can have their own pool however
which would reduce that greatly. If they have their own pool, then we also have a
potential problem of contamination of the qualifier pool.

We can further reduce global contamination by enhancing the include system.
My preference would be to break existing behaviour and add the ability to
declare includes as global. To access a global in an include file one would then
have to include the file as global. If the file A were nested in another include
file B, then file A would have to be globall included in file B and file B would
have to be globally included in the current file.
This is called chaining and would alleviate a huge majority of all global
conflicts on it's own.
The same thing could be achieved without breaking compatability by introducing a
new keyword. But I don't think it's as elegant.

An additional way to reduce contamination would be to allow locals (including
local namespaces) to be accessed globally by qualifying them.


Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria

24. Re: Global = root of all evil

• Posted by ags <eu at 531pi.co.nz> Nov 06, 2006
• 605 views

Derek Parnell wrote:
> If we had the situation where every name collision had to be disambiguated
> using
> namespace ids, and if one wanted to refer to a 'y()' routine that was local
> to the current file, how would one indicate that? I mean, is it possible that
> the current file can have a predefined namespace identifier ... ?
> 
>    fr:f( fr:x(), this:y(), fr:z() )

I think in Perl you can use main::y(), but there's no need because if it isn't
qualified then it's assumed to be in "main".

Gary

26. Re: Global = root of all evil

• Posted by ags <eu at 531pi.co.nz> Nov 06, 2006
• 591 views

ags wrote:
> 
> Derek Parnell wrote:
> > If we had the situation where every name collision had to be disambiguated
> > using
> > namespace ids, and if one wanted to refer to a 'y()' routine that was local
> > to the current file, how would one indicate that? I mean, is it possible
> > that
> > the current file can have a predefined namespace identifier ... ?
> > 
> >    fr:f( fr:x(), this:y(), fr:z() )
> 
> I think in Perl you can use main::y(), but there's no need because if it isn't
> qualified then it's assumed to be in "main".

"I meant to add" ...

In Perl you can export a routine or variable, so that it is seen in 'main', but
that too is considered to be contamination to be used sparingly.

I know I go on about Perl, but I really do like it's 'include' system.  It has
version control, object orientation, is based on directory structure, etc etc,
but it can still be used as a basic system like Euphoria's.

The only problem with it is that it's as unfriendly to use as some of Perl
itself.

Gary

28. Re: Global = root of all evil

• Posted by ags <eu at 531pi.co.nz> Nov 08, 2006
• 623 views

Pete Lomax wrote:
> 
> Ho hum, if it weren't for the likes of me, you'd not appreciate normal
> 
> 

Hey, too true. :)

Did we actually decide anything in the whole "global = evil" thing??

Gary