1. ver 4 and ver 3.11 function name conflicts

You are using a the global function called get() in map.e and another 
function get() is used in get.e include file. 
 
I thought you said that there would be no conflicts between 3.11 and 4.0 
include files.  

new topic     » topic index » view message » categorize

2. Re: ver 4 and ver 3.11 function name conflicts

bernie said...

You are using a the global function called get() in map.e and another function get() is used in get.e include file.

I thought you said that there would be no conflicts between 3.11 and 4.0 include files.

There are of course naming conflicts. 1/3 of the 4.0 library is the 3.1 library. So, abs, round, etc... all exist in the 3.1 includes as well as the 4.0 includes. Now, standard practice for many of the 4.0 libs is to use default namespaces, which are declared in the actual file being included. You can of course override them via the "as mynamespace" syntax. Here is an example on how to use map, regex and get.e together:

include std/map.e 
include std/regex.e 
include get.e as old_get 
 
map m = map:new() 
regex r = regex:new() 
? old_get:get() 
? map:get(m, "name") 

Jeremy

new topic     » goto parent     » topic index » view message » categorize

3. Re: ver 4 and ver 3.11 function name conflicts

jeremy said...
include std/map.e 
include std/regex.e 
include get.e as old_get 
 
map m = map:new() 
regex r = regex:new() 
? old_get:get() 
? map:get(m, "name") 

Is the "default namespace" for a file the filename sans extension? or is it otherwise defined?

new topic     » goto parent     » topic index » view message » categorize

4. Re: ver 4 and ver 3.11 function name conflicts

euphoric said...

Is the "default namespace" for a file the filename sans extension? or is it otherwise defined?

There is no automatic default namespace, nor a rule on what a default namespace has to be nor does the docs currently say what the default namespace is smile We just started using them and have not yet documented that.

You could have:

-- yugo.e 
namespace porche 
function win_race() 
 
-- myprog.ex 
include yugo.e 
 
? porche:win_race() 

As a standard in the std library I think it will be the filename but we have not discussed that and there may be cases where it does not make sense to be. For instance:

ifdef DOS32 then 
    include dos_racer.e 
elsifdef WIN32 then 
    include win_racer.e 
end ifdef 
 
racer:start() 

Jeremy

new topic     » goto parent     » topic index » view message » categorize

5. Re: ver 4 and ver 3.11 function name conflicts

jeremy said...
euphoric said...

Is the "default namespace" for a file the filename sans extension? or is it otherwise defined?

There is no automatic default namespace...

When you created your example, you used map:xxx and regex:xxx. Where did those namespaces come from? I didn't see them defined in the sample program (reproduced below), as you did with "include get.e as old_get."

include std/map.e  
include std/regex.e  
include get.e as old_get  
  
map m = map:new()  
regex r = regex:new()  
? old_get:get()  
? map:get(m, "name")  
new topic     » goto parent     » topic index » view message » categorize

6. Re: ver 4 and ver 3.11 function name conflicts

euphoric said...
jeremy said...
euphoric said...

Is the "default namespace" for a file the filename sans extension? or is it otherwise defined?

There is no automatic default namespace...

When you created your example, you used map:xxx and regex:xxx. Where did those namespaces come from? I didn't see them defined in the sample program (reproduced below), as you did with "include get.e as old_get."

include std/map.e  
include std/regex.e  
include get.e as old_get  
  
map m = map:new()  
regex r = regex:new()  
? old_get:get()  
? map:get(m, "name")  

It came from inside of std/regex.e and std/map.e ... they contain 1 line of code that looks like:

namespace map 
-- or -- 
namespace regex 

What I meant by automatic is a file w/o a namespace keyword does not get a default namespace assigned to it. The programmer of map.e must decide that a default namespace would be handy and issue a default namespace him/herself.

Jeremy

new topic     » goto parent     » topic index » view message » categorize

7. Re: ver 4 and ver 3.11 function name conflicts

jeremy said...

What I meant by automatic is a file w/o a namespace keyword does not get a default namespace assigned to it. The programmer of map.e must decide that a default namespace would be handy and issue a default namespace him/herself.

Ahhh. Gotcha. Thanks! smile

new topic     » goto parent     » topic index » view message » categorize

8. Re: ver 4 and ver 3.11 function name conflicts

jeremy said...
euphoric said...
jeremy said...
euphoric said...

Is the "default namespace" for a file the filename sans extension? or is it otherwise defined?

There is no automatic default namespace...

When you created your example, you used map:xxx and regex:xxx. Where did those namespaces come from? I didn't see them defined in the sample program (reproduced below), as you did with "include get.e as old_get."

include std/map.e  
include std/regex.e  
include get.e as old_get  
  
map m = map:new()  
regex r = regex:new()  
? old_get:get()  
? map:get(m, "name")  

It came from inside of std/regex.e and std/map.e ... they contain 1 line of code that looks like:

namespace map 
-- or -- 
namespace regex 

What I meant by automatic is a file w/o a namespace keyword does not get a default namespace assigned to it. The programmer of map.e must decide that a default namespace would be handy and issue a default namespace him/herself.

Jeremy

In other words every time I write a program I do all this extra work
of typing a foo:get()

That stinks !

Now you have functions with same name all over the place even in the same
directory.

new topic     » goto parent     » topic index » view message » categorize

9. Re: ver 4 and ver 3.11 function name conflicts

bernie said...

In other words every time I write a program I do all this extra work
of typing a foo:get()

That stinks !

Now you have functions with same name all over the place even in the same
directory.

No Bernie, that is not the case.

You only need to use a namespace if your program uses clashing names.

But consider the alternative. Assume we didn't have namespaces.

include std/map.e  
include std/regex.e  
include get.e 
  
map m = map_new()  
regex r = regex_new()  
? get()  
? map_get(m, "name")  

Not much difference is there? If we didn't have namespaces, then each library would have to come up with a special word for each of its routines. For example if we used prefixes, all routines in a library should be prefixed to minimize name clashes (we can never entirely get rid of them). So all map.e routines could have "map_" as a prefix, etc ... In which case, there is little difference between this and namespaces, except that we would be forced to type prefixes but are not always forced to type namespaces.

Another alternative is to use 'unique' names for routines. eg.

include std/map.e  
include std/regex.e  
include get.e 
  
map m = create()  
regex r = construct()  
? get()  
? fetch(m, "name")  

We soon run out of synonyms and we add a bit of confusion because if we come across a line of code "a = retrieve(x)" we don't know easily what that does doing or where it comes from. But if we see "a = memory:get(x)" we might get a clue or two. Plus, what do we do if two indenpendant libraries declare the same name anyway?

new topic     » goto parent     » topic index » view message » categorize

10. Re: ver 4 and ver 3.11 function name conflicts

DerekParnell said...
bernie said...

In other words every time I write a program I do all this extra work
of typing a foo:get()

That stinks !

Now you have functions with same name all over the place even in the same
directory.

No Bernie, that is not the case.

You only need to use a namespace if your program uses clashing names.

But consider the alternative. Assume we didn't have namespaces.

include std/map.e  
include std/regex.e  
include get.e 
  
map m = map_new()  
regex r = regex_new()  
? get()  
? map_get(m, "name")  

Not much difference is there? If we didn't have namespaces, then each library would have to come up with a special word for each of its routines. For example if we used prefixes, all routines in a library should be prefixed to minimize name clashes (we can never entirely get rid of them). So all map.e routines could have "map_" as a prefix, etc ... In which case, there is little difference between this and namespaces, except that we would be forced to type prefixes but are not always forced to type namespaces.

Another alternative is to use 'unique' names for routines. eg.

include std/map.e  
include std/regex.e  
include get.e 
  
map m = create()  
regex r = construct()  
? get()  
? fetch(m, "name")  

We soon run out of synonyms and we add a bit of confusion because if we come across a line of code "a = retrieve(x)" we don't know easily what that does doing or where it comes from. But if we see "a = memory:get(x)" we might get a clue or two. Plus, what do we do if two indenpendant libraries declare the same name anyway?

Thanks derek.
I understand your explaination.

What I thought that the interpreter would do was always
go to use any library in the std directory first because of std/foo.e

It would use the file foo.e in a different directory when I included
it like mydir/foo.e as mine .

In other words I thought that the std directory was special and was
a special namespace.

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu