1. ver. 4.0 std include files type conflict
- Posted by bernie Mar 18, 2009
- 855 views
set.e contains:
- public type map
map.e contains:
- public type map
2. Re: ver. 4.0 std include files type conflict
- Posted by bernie Mar 18, 2009
- 878 views
set.e contains:
- public type map
map.e contains:
- public type map
That should have been SETS.E
3. Re: ver. 4.0 std include files type conflict
- Posted by jeremy (admin) Mar 18, 2009
- 835 views
There are other conflicts, such as new in regex.e, pcre.e, stack.e and map.e. There are conflicts with some internal methods as well, for instance, regex.e's find().
With the new standard library, there are over 600 public symbols now. It's impossible to make each one have a clean API and not have a conflict with another. For this reason, namespaces were created:
include regex.e as re include pcre.e as pcre include stack.e as st include map.e as m m:new() st:new() pcre:new() re:new()
They all live together peacefully.
Jeremy
4. Re: ver. 4.0 std include files type conflict
- Posted by mattlewis (admin) Mar 18, 2009
- 848 views
There are other conflicts, such as new in regex.e, pcre.e, stack.e and map.e. There are conflicts with some internal methods as well, for instance, regex.e's find().
...
They all live together peacefully.
That's true, but I think this is adding confusion as to the type of map we're dealing with. I haven't really looked at sets.e previously, so I'm not familiar with it. While we define multiple routines that do similar things to different types of data, here we're talking about different types of data.
Looking at the documentation that's there, a sets:map appears to be a sequence of indices that define the permutation to make sequence s1 into sequence s2. So it's true that it 'maps' between the two sequences, but maybe not the most appropriate name.
I think this particular instance is a good catch by Bernie. Here are some suggestions that come quickly to mind:
- permutation
- index_map
- translation
Matt
5. Re: ver. 4.0 std include files type conflict
- Posted by jeremy (admin) Mar 18, 2009
- 855 views
That's true, but I think this is adding confusion as to the type of map we're dealing with. I haven't really looked at sets.e previously, so I'm not familiar with it. While we define multiple routines that do similar things to different types of data, here we're talking about different types of data.
Looking at the documentation that's there, a sets:map appears to be a sequence of indices that define the permutation to make sequence s1 into sequence s2. So it's true that it 'maps' between the two sequences, but maybe not the most appropriate name.
Guess I was too quick on this one, I have not looked at sets either.
I think this particular instance is a good catch by Bernie. Here are some suggestions that come quickly to mind:
- permutation
- index_map
- translation
Namespaces work for types as well and I do not see a problem with that, however, there is no reason to have a conflict because something is named incorrectly, or a better name exists for one of them. The above suggestions for changing set, also map.e is frequently called a dictionary, or dict. I am unsure of what is the most common word for what we have in map.e.
Jeremy
6. Re: ver. 4.0 std include files type conflict
- Posted by bernie Mar 18, 2009
- 855 views
There are other conflicts, such as new in regex.e, pcre.e, stack.e and map.e. There are conflicts with some internal methods as well, for instance, regex.e's find().
With the new standard library, there are over 600 public symbols now. It's impossible to make each one have a clean API and not have a conflict with another. For this reason, namespaces were created:
include regex.e as re include pcre.e as pcre include stack.e as st include map.e as m m:new() st:new() pcre:new() re:new()
They all live together peacefully.
Jeremy
Thanks Jeremy:
I'am having a problem and I'am having a map type conflict
some where in my code so I just noticed that while trying to
find the problem.
With the error I'am getting the ex.err does tell me where
the conflict is just that I have one.
7. Re: ver. 4.0 std include files type conflict
- Posted by jeremy (admin) Mar 18, 2009
- 874 views
I'am having a problem and I'am having a map type conflict some where in my code so I just noticed that while trying to find the problem.
With the error I'am getting the ex.err does tell me where the conflict is just that I have one.
Hm, that's not so nice. Can you paste the interpreter output and ex.err here so I can see the exact output and maybe track it down a bit?
Jeremy
8. Re: ver. 4.0 std include files type conflict
- Posted by bernie Mar 18, 2009
- 855 views
I'am having a problem and I'am having a map type conflict some where in my code so I just noticed that while trying to find the problem.
With the error I'am getting the ex.err does tell me where the conflict is just that I have one.
Hm, that's not so nice. Can you paste the interpreter output and ex.err here so I can see the exact output and maybe track it down a bit?
Jeremy
Jeremy:
I was trying to get the load_map RAW to work
and I some way corrupted my include files
so I wiped out my std includes and reloaded the
latest includes.Now the problem has gone away.
I can't build any binaries beyond SVN 1472 so I
trying to work with the SVN 149x includes with SVN 1472 binaries.
save_map works in both text and raw mode.
load_map works in text mode but fails in raw mode
so thats what I'am doing and I'll let you know if the problem reoccurs.
9. Re: ver. 4.0 std include files type conflict
- Posted by mattlewis (admin) Mar 18, 2009
- 872 views
Namespaces work for types as well and I do not see a problem with that, however, there is no reason to have a conflict because something is named incorrectly, or a better name exists for one of them. The above suggestions for changing set, also map.e is frequently called a dictionary, or dict. I am unsure of what is the most common word for what we have in map.e.
Yeah, they definitely do work. I just think that it's poor form to release the standard library as a unit that has multiple, distinct types with the same name.
As far as map.e is concerned, Java and C would also call it a map. Perl would call it a hash. In Python and Lua, I believe it's a dictionary, and in Javascript, an associative array.
My preference for map probably betrays my programming lineage.
Matt
10. Re: ver. 4.0 std include files type conflict
- Posted by bernie Mar 18, 2009
- 841 views
I found what is causing the type conflict error.
If a user places a 'with trace' at the top of the
of map.e include file and the user program is using
the map.e in a program; starting the program will report
the following error.
------------------------------------- C:\EU_MASTER\INCLUDE\std/map.e:161 attempt to redefine map public type map(object obj_p) ^ Press Enter -------------------------------------
Also 'with profile' does the same thing.
Even if you put 'include std/safe.e' at top of
map.e you get the same error.
You can create the problem with the following.
------------------------------------- -- place 'with trace' at top of map.e -- use the following code in a exw program include std/map.e if getc(0) then -- pause end if -------------------------------------
11. Re: ver. 4.0 std include files type conflict
- Posted by jeremy (admin) Mar 18, 2009
- 885 views
Bernie,
Your example works fine here. Is something else missing from your example?
include std/map.e if getc(0) then -- pause end if
Jeremy
12. Re: ver. 4.0 std include files type conflict
- Posted by mattlewis (admin) Mar 18, 2009
- 846 views
I found what is causing the type conflict error.
If a user places a 'with trace' at the top of the
of map.e include file and the user program is using
the map.e in a program; starting the program will report
the following error.
It's giving a misleading error. It's not a 'type conflict error' that's being reported. The actual issue is that a default namespace declaration must be the first token to be parsed in a file. Comments are ok, but nothing else.
I think that what's going on is that namespace is determined to be a forward type reference, and so it defines a new variable named mapnamespace isn't a reserved word, though maybe it should be. Then it comes across a type named map, and now you have multiple symbols in the same scope with the same name.
Matt
13. Re: ver. 4.0 std include files type conflict
- Posted by bernie Mar 18, 2009
- 860 views
I found what is causing the type conflict error.
If a user places a 'with trace' at the top of the
of map.e include file and the user program is using
the map.e in a program; starting the program will report
the following error.
It's giving a misleading error. It's not a 'type conflict error' that's being reported. The actual issue is that a default namespace declaration must be the first token to be parsed in a file. Comments are ok, but nothing else.
I think that what's going on is that namespace is determined to be a forward type reference, and so it defines a new variable named mapnamespace isn't a reserved word, though maybe it should be. Then it comes across a type named map, and now you have multiple symbols in the same scope with the same name.
Matt
Matt:
If you take the 'with trace' out of the map.e
and then place the 'with trace' in the test program like this:
------------------------------------- -- use the following code in a exw program with trace -- <- outside of map.e include std/map.e if getc(0) then -- pause end if -------------------------------------
Then the error does not occur.
So it looks like it has something to do with
namespace like you say.
