1. New map routines
- Posted by Aku <akusaya at g??.net> Apr 20, 2008
- 564 views
I just committed new routines for map data structures. The new include file is map.e The new routines are map_new, map_put, map_get, map_size, map_remove, map_keys, and map_values. http://rapideuphoria.svn.sourceforge.net/svnroot/rapideuphoria/trunk/doc/library.doc The keys and values can be any object. The hash function is in pure Eu (no asm codes), and it seems faster than other hashmap libraries in the archives (need more tests, actually). Suggestions etc are welcome :)
2. Re: New map routines
- Posted by Jeremy Cowgar <jeremy at c?wg?r.com> Apr 20, 2008
- 553 views
I was looking at it, cool! Was the unit testing OK to work with? Also, 2 suggestions, please remember to update the relnotes.htx w/what you've added and your name. We tend to bold keywords that will get peoples attention such as files changed/added (map.e) and functions changed/added. Also, I wonder if we should make the type name lower case instead of mixed as to fit in with the other types, i.e. integer, atom, object not Integer Atom or Object? -- Jeremy Cowgar http://jeremy.cowgar.com
3. Re: New map routines
- Posted by Jeremy Cowgar <jeremy at c?wgar?com> Apr 20, 2008
- 547 views
I was looking at it, cool! Was the unit testing OK to work with? Also, 2 suggestions, please remember to update the relnotes.htx w/what you've added and your name. We tend to bold keywords that will get peoples attention such as files changed/added (map.e) and functions changed/added. Also, I wonder if we should make the type name lower case instead of mixed as to fit in with the other types, i.e. integer, atom, object not Integer Atom or Object? -- Jeremy Cowgar http://jeremy.cowgar.com
4. Re: New map routines
- Posted by Jeremy Cowgar <jeremy at ?owgar.co?> Apr 20, 2008
- 551 views
Oh, also, on the last commit. unittest.e is a general testing framework that anyone can use. I use it in many applications of my own and in other libraries, so it should stay in euphoria/include. Thus, it can be a standard unit testing framework in which others can test their application. I just have not documented it yet. -- Jeremy Cowgar http://jeremy.cowgar.com
5. Re: New map routines
- Posted by Aku <akusaya at g?x.ne?> Apr 20, 2008
- 567 views
Jeremy Cowgar wrote: > I was looking at it, cool! Was the unit testing OK to work with? Also, 2 > suggestions, > please remember to update the relnotes.htx w/what you've added and your name. > We tend to bold keywords that will get peoples attention such as files > changed/added > (map.e) and functions changed/added. > > Also, I wonder if we should make the type name lower case instead of mixed as > to fit in with the other types, i.e. integer, atom, object not Integer Atom > or Object? Thanks! Yes, the unit testing is OK and quite simple to use. I have updated the relnotes just now. Some 0.01 cents... How about the object(x) proposal again that may return 0 for no value? It is very useful for hashmap routines.. Now the hash_get function is used like:
object value value = hash_get(map, key, -1) if value = -1 then -- not found else -- found end if
With the new object function we can have Now the hash_get function is used like:
object value value = hash_get(map, key) if not object(value) then -- not found else -- found end if
6. Re: New map routines
- Posted by Aku <akusaya at ?mx.n?t> Apr 20, 2008
- 583 views
Jeremy Cowgar wrote: > Also, I wonder if we should make the type name lower case instead of mixed as > to fit in with the other types, i.e. integer, atom, object not Integer Atom > or Object? I forgot to reply about this. I want to know how the others think about this new object type, should it be Map or map? Maybe if we use "map" we cannot have any variable called "map" again and will break so many codes?
7. Re: New map routines
- Posted by Jeremy Cowgar <jeremy at cow?ar.?om> Apr 20, 2008
- 561 views
Aku wrote: > > Jeremy Cowgar wrote: > > Also, I wonder if we should make the type name lower case instead of mixed > > as > > to fit in with the other types, i.e. integer, atom, object not Integer Atom > > or Object? > > I forgot to reply about this. > I want to know how the others think about this new object type, > should it be Map or map? > > Maybe if we use "map" we cannot have any variable called "map" again > and will break so many codes? We are defining a new API as we go on. I do not think we should define the new API based on possible variable names. I think a set standard and language consistency are much more important. Changing a variable name is easy. With the new release, I think no matter how hard we try, we are going to break some peoples code. I think at all costs we should keep the language consistent. Also, when naming variables, a variable name of map is really not a good programming practice. Just as I would not create a variable name Integer. No one does that because of an existing type of integer. On the inverse, you shouldn't create a variable name of map with a type of Map. We see this often in simple OO programming examples. But, it's not a good name nor a good example. When I read through code, and I see a variable name called "map" I would ask, ok, it's a map, but of what? Therefore, to further my side, I especially think we should not design the new interface based on possible bad naming schemes of variable names. I firmly believe that keeping language consistency is of much more importance. Now, this is not to say we should ignore the fact that we may break programs. With useless changes, that would be a problem, for instance, we shouldn't introduce a function named "i" which returns the index of a value in an array. That would just be silly. But, with Map, I think it really needs to be map. We can wait for what others think as well, but again, Euphoria is a simple language and if we starting making it inconsistent, we are going to ruin it. -- Jeremy Cowgar http://jeremy.cowgar.com
8. Re: New map routines
- Posted by Aku <akusaya at g?x.n?t> Apr 20, 2008
- 566 views
Jeremy Cowgar wrote: > We are defining a new API as we go on. I do not think we should define the new > API based on possible variable names. I think a set standard and language > consistency > are much more important. Changing a variable name is easy. > > With the new release, I think no matter how hard we try, we are going to break > some peoples code. > Therefore, to further my side, I especially think we should not design the new > interface based on possible bad naming schemes of variable names. I firmly > believe > that keeping language consistency is of much more importance. I see your point. From the beginning until now, I guess what RDS trying to do was to maintain as much compatibility with older versions of Eu. However, it become really old and I think we became very limited in progression. If the intention of the next release is to somewhat "revolutionize" the language by breaking compatibility but with some good progress, I think we can do it. I will commit soon. I still wonder about the var-args routines. Can someone who understands the source give some light about it?