1. Re: Why doesn't this work?
Jim and Derek, thanks for your explanations!
Derek wrote:
> From: "Juergen Luethje" <j.lue at gmx.de>
>
>> Hello Jim, you wrote:
>>
>>> It fails, simply because, inc_2.e has no show() routine defined.
>>>
>>> inc_1.e does, and inc_a.e does, but neither of them are in the "two"
>>> namespace.
>>
>> But the show() routine in 'inc_a.e' is global, 'inc_a.e' is included in
>> 'inc_2.e', and 'inc_2.e' has the "two" namespace assigned.
>
> What Jim was meaning was that inc_2.e does not CALL the routine named
> 'show()', rather than is doesn't contain the routine. Namespace clashes ONLY
> occur when duplicated names are referred to. Simply including them doesn't
> cause an error or warning message.
>
>
> Your code ...
> ------=-------------------------=------
> -- main.exw
> include inc_1.e as one
> include inc_2.e as two
>
> one:show() -- means call the 'show' routine DEFINED in inc_1.e
> two:show() -- means call the 'show' routine DEFINED in inc_2.e
>
> however if inc_2.e looks like this...
>
> ------=-------------------------=------
> -- inc_2.e
> include inc_a.e
> ------=-------------------------=------
>
> you can see that there is NO 'show' routine defined in this file. The 'show'
> routine is actually defined in inc_a.e. Thus if that's the one you really
> want to call, you need to write in you main program this ...
>
>
> -- main.exw
> include inc_1.e as one
> include inc_2.e
> include inc_a.e as two -- Yes, even though it is already included in
> inc_2.e !!
>
> one:show() -- means call the 'show' routine DEFINED in inc_1.e
> two:show() -- means call the 'show' routine DEFINED in inc_a.e
>
>> Does that mean, that the namespace of a global symbol has not the same
>> <looking for a proper english word...> size/reaching distance/range than
>> it's scope? (Is this understandable?)
Variables and routines have a "scope". Can one of you experts please
tell me, what the proper english term regarding to namespaces is. Do
they also have a "scope"? It's hard to talk about things, without
knowing the proper words.
>> That confuses me. I also didn't find an explanation in the docs.
>
> Namespaces are local. They only last as long as the file they are defined
> in. You cannot 'see' the namespace that was defined inside another file.
Ah, I see.
>>> I feel this is correct behavior (if you want to access inc_a.e's routine
>>> directly, include it directly in main.exw).
>>
>> But without an explicite namespace, 'inc_a.e's routine can also be
>> accessed, if 'inc_a.e' is included indirectly in 'main.exw' via
>> 'inc_2.e'.
>
> Realize that just including a file does NOT cause namespace clashes - you
> must also refer to the duplicated global name to cause an error.
>
>> (I wrote another, for me even more surprising example at the end of this
>> post.)
>>
>>> jbrown
<snip>
>> ---------=--------------[ New example ]---------------=---------
>>
>> ------=-------------------------=------
>> -- inc_a.e
>> global procedure show ()
>> puts(1, "printing from 'inc_a.e'\n")
>> end procedure
>> ------=-------------------------=------
>>
>> ------=-------------------------=------
>> -- inc_2.e
>> include inc_a.e
>> ------=-------------------------=------
>>
>> ------=-------------------------=------
>> -- main.exw
>> include inc_2.e
>>
>> show()
>> ------=-------------------------=------
>
> Of course it does. Because there is only ONE global symbol called 'show'.
There's no doubt about it, not even for me. 
>> The code above works fine. Now I just add an explicite namespace in
>> 'main.exw', which is a legal operation, and it doesn't work anymore
>> (all the time talking about v2.4 Beta, of course):
>>
>> ------=-------------------------=------
>> -- main.exw
>> include inc_2.e as two
>>
>> two:show()
>
> It doesn't work because the line "two:show()" means "call the routine named
> 'show' that has been DEFINED in the namespace 'TWO'". And there isn't one in
> this example!
>
>> ------=-------------------------=------
>>
>> This confuses me, and is IMHO in contrast to simplicity, one of
>> Euphoria's great advantages.
>>
>
> Most things are simple once you know the rules.
Partly I do agree ...
> And the rule when using
> namespace qualifiers is that the thing you are referring to must be DEFINED
> in the namespace - not just indirectly included.
... that's why I'd appreciate it very much, if this would be explained
in the docs as clear as you did here. For hobbyists like me, who have
not already discussed such stuff in depth at university (or wherever),
this is essential.
-~----~-----~-----
Partly I do not agree to the statement:
| Most things are simple once you know the rules.
because unfortunately there are many things, that are more complicated
than necessary. For example some video recorders, cameras, washing
machines... I know, that the complicated operation of washing machine #1
isn't necessary, when I see washing machine #2, that is easy to operate,
and gives me the same or even better results. The science called
ergonomics deals with such things. And you cannot change a unnecessarily
complicated washing machine into a good one, just by saying that people
should read the 150 pages of the manual, so that they know the rules.
Sorry, but I cannot resist to tell a famous anecdote from Germany in
this context:
In the years 1974-1982, the chancellor of the Federal Republic of
Germany was Helmut Schmidt, a man with an intelligence above average
(this was even admitted by the opposition 
).
Once he told in public, that his private electricity invoice [proper
expression?] was so complicated, that he wasn't able to understand it.
Do you think the invoice was *necessarily* so complicated? Would you
have told him: "Hey man, just go to your electric power company, and
read several hundredes of pages in their files, then you know the rules,
and it will be simple to understand the invoice."? )
It's similar with programming languages. That's why Rob says: "Just say
'no' to complicated programming languages." And as we all know, he
writes more about this subject in the docs, e.g. in
http://www.rapideuphoria.com/c.htm.
Igor wrote today on this list:
| Good programming language MUST be clear.
If the name of a variable or routine has another scope than the
namespace in which it is included, this is neither clear, nor intuitive,
nor simple. Please note that for you experts more or less anything is
simple; that's different from what is considered simple by people who
are not experts.
This must be enough for the moment. Thanks for the attention to anyone
who read until here, and thanks again you Jim and Derek, for your
explanations.
Best regards,
Juergen
--
/"\ ASCII ribbon campain | Everything should be made as simple
\ / against HTML in | as possible, but not simpler.
X e-mail and news, |
/ \ and unneeded MIME | http://www.sfheart.com/einstein.html
