Re: named array
- Posted by TheresNoTime Sep 04, 2013
- 2039 views
My method uses sequences because they initially do not have such effect.
But sequences are mutable!
Yes, of course, I can write
narr Person[1] = "James"
instead of
narr Person = put(Person, "name", "James")
if I absolutely sure, that key "name" = index 1 in that map. But it is dirty hack, that I'm not going to do. Otherwise, it is unclear why it was a fuss?
Theoretically, there is a much more efficient way. Write a preprocessor that looks for all the indexes and stores them in a list. For example, when it saw
abc = x[_A] + x[_B] + x[_C] -- underlining is used to indicate keys (that "symbols" in terms of Ruby)
then it creates file symbols.e, that contains
public enum _A, _B, _C public function new() return repeat(0, 3) -- because we have only 3 symbols end function
I just came to mind. Perhaps I will do so. Not because it's faster, but because it will take away a lot of repetitive lines
sequence Name = get(my_narr, "name") sequence Work = get(my_narr, "work")
The disadvantage is that it will lead to the need to monitor changes of consistency and make clones. But it will be much easier.
sequence NewState = State NewState[_VELOCITY] = NewVelocity return isAccident(NewState) -- State isn't changed, NewState is eaten by garbage collector
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.
Hmmm... No. I did not say so. In the middle of the conversation mentioned structure "map of maps". My narr is simpler than that.
I content that 1) your library merely implements an immutable map datatype.
If you say about one narr - yes. If you say about narrs - no. My narrs is more effective than set of maps, because keys stored in single table. I spied this principle in Ruby. I know that this is not in Python. And I'm not even sure that the atoms of the Erlang are analogous to Ruby's symbols.
2a) A naive or simple implemantation is not always best.
Of course. I'm not going to make a production version. If the Ruby I spied the principle of symbols, the Erlang I spied principle "Let It Crush".
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.
Oh no, again... Map of keys absolutely invisible. narr is regular sequence. About effectivness. As far as I guess, fetching some stuff form sequence is almost instantaneous operation. It is pointer internally, eh? So, narr is almost equal to map, because it do two actions only: get index from map by key, get value from sequence by index.
