Re: named array
- Posted by jimcbrown (admin) Sep 04, 2013
- 1993 views
Yes, it is possible. But why? For what reason? Do you not see that either way - it's my way, but unnecessarily complicated.
Maps make use of eumem. Your library uses sequences (and a map...) directly. Otherwise, the two are identical. Aside from an explicit copy() call (which your library simply does implicitly), and the complexity inherent to the use of eumem (which is hidden from the map user due to data encapsulation) there is no additional complexity.
Your variation of "willAccident" is shorter, but you just put some of my code into a separate function "clone_and_put". This is the same backup and restore (just disguised), but for the entire map! Pfff...
Looking at it that way, the original map version (requiring a manual restore) is the most efficient. Both your library and my map version require a full (ableit shallow, as opposed to a deep) copy of the dictionary data structure to be made. In both cases this is just a sequence that is copied (as eumem is implemented as a big sequence) - but the original map version saves us that effort (at the cost of changing the original).
Keep in mind that map:clone() benefits from the COW nature of Euphoria sequences. So it's simply a shallow, rather than a deep, copy. For that reason, I say the two approaches (my map version and your library version) are on an equal footing.
Your way of using maps plus a crutch to overcome their side effect.
I was demonstrating that it was possible to use a mutable datatype without actually changing it. Thus, there are no side effects to overcome.
My method uses sequences because they initially do not have such effect.
But sequences are mutable!
Yes, you will have one simple function, and I have three plus the map for keys "behind the scenes".
Strictly speaking, it's not necessary to add even this single function, copy_and_put(), as I demonstrated in the earlier example...
However, if you look at the principle, not to it's implementation, my approach is simpler. It is better to have a new type of data than to remember that it is necessary to use a crutch for old type.
And we're back to the addition of an immutable map type. There are cases where an immutable type is valuable (as you don't trust the other function or library to avoid mutating your data structures), and other languages do follow this principle (having both a immutable String type and a mutable StringBuilder type). In many cases, it simply makes sense to have this distinction enforced by the language itself.
However, I should point out here that you have made a small fuss about the necessity of leaving the original object unchanged without providing any justification why this is necessary. You furthmore seem to be saying that your library implementation is superior to that of maps (or at least implying that this is the case) without really explaining why. Your efforts at explaining this all center on two factors: 1) Your library implements an immutable data structure. 2) Your library is simpler than the Euphoria map implementation.
I content that 1) your library merely implements an immutable map datatype. 2a) A naive or simple implemantation is not always best. (Simple algorithms can be slower than highly optimized ones, for example.) 2b) Your library uses Euphoria maps internally, so it's not really simpler anyways - the combined logic in its totality must be more complex, since any complete and total description of your library must include a description of the Euphoria implementation of maps and eumem. Perhaps your library is the one with a crutch, using maps internally to deal with keys instead of coming up with a more efficient implementation to handle them.
But this may be really getting off track, since you seem to have originally wanted something like Erlang's atoms. Those may be implemented by a big global map structure internally (to connect the string that represents the symbol with the integer that represents the hash that is used), but that's a hidden detail from the user of the language. In actuality, it appears as a entirely new class of datatype - not integer, or floating point, or string, or a class or structure or array composed of multiples of these, but a new kind of literal altogether.
