I just got a fascinating idea, I wonder how a map of maps would work as such a tree like this instead of tuples... I may have to test that next...
On Friday, June 17, 2016 at 2:39:42 PM UTC-6, OvermindDL1 wrote: > > Indeed, which is why using it as a tuple function call makes the most > sense for tuples, the first element being an atom that is the module that > the 'fetch' function should be called on, if not an atom then the match > fails, thus consistent with normal tuple call syntax. :-) > > On another note, is there really no Elixir'ish array module. I used maps > before but it was taking almost thirty seconds to generate some of these > reports, replaced it with erlangs array module and it fell to <1s, so I > made a replacement module but I would really love not to have to upkeep it, > especially if one already exists elsewhere. :-) > > On Friday, June 17, 2016 at 2:32:11 PM UTC-6, José Valim wrote: >> >> As a protocol it would be considered to have no tuple implementation >>> though, of which I could then supply. >>> >> >> Yes and no. You could but it wouldn't be semantically correct. What if >> someone else implement their own "fake" data type with tuples and want to >> use the tuple implementation? It wouldn't compose and the code would just >> fail. >> > -- You received this message because you are subscribed to the Google Groups "elixir-lang-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/57e88900-6b81-4a3f-9751-c021a2e0e8d6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
