Hi Robert, "(...) Shouldn't tuples get functional interface 'a la' existing records, but for tuples in general, not necessarily for tuples being at once 'records'?"
Strictly speaking `Record.defrecord(p)/2,3` macro produces a set of `record/0,1,2` (substitute record with actual name given by user) which are... macros. In use these generated macros look like function calls (even in pattern-match contexts), and that's why I wrote functional. The macros address all problems you listed and offers other goodies, esp. record/1 macro is nicely "overloaded". For example, for given field name (literal atom at compile time) returns zero-based index of that field in a tuple (e.g. name(:user) returns integer at compile time). The problem with records I encountered is they are *specific* tuples. I need tuples not being records (for a good reason IMO) but with the same API Elixir records do offer. That's why I proposed `Tuple.deftuple(p)/2` generating `tuple/0,1,2`. The code doing it, as one can suspect, has been stolen from Record module and adopted for general-tuples-not-records. As the proposal seemed to be rejected, at least for now, I am going to publish the code on github. Waldemar. On Mon, Nov 7, 2016 at 11:26 AM, Robert Virding <[email protected]> wrote: > How do you mean a "functional interface". One issue with pattern matching > a tuple is that you have to write the whole tuple. There is no way of > saying to test if it is a tuple and is the Nth element 42. The (erlang) > record interface does this expansion in a pattern, it expands the more > functional interface to the right sized tuple where the first element is > the record name, the elements in which you are interested to the patterns > you give and all the other elements become _ so as to match anything[*]. So > a tuple interface must do the same thing, which is why I was asking about > the functional interface. > > Robert > > [*] You can do the "matching" in a guard if you wish but then the macro > becomes more complex. The record interface expansion in the body is the > basically same except that instead of _ for the other elements there is the > default values. > > On Friday, 4 November 2016 14:46:54 UTC+1, Waldemar Rachwał wrote: >> >> Only skimmed Inspect.Algebra... Could those macros give possibilities to >> achieve what Record.defrecord/3 provides? Among other things: >> pattern-matching capabilities, "tell me index of the field by name"... >> >> Maybe I should have avoided dwelling on my use case, and formulate more >> general wish: Shouldn't tuples get functional interface 'a la' existing >> records, but for tuples in general, not necessarily for tuples being at >> once 'records'? >> >> Regards, >> Waldemar. >> >> On Fri, Nov 4, 2016 at 1:21 PM, José Valim <[email protected] >> > wrote: >> >>> In such cases, I use macros: >>> >>> https://github.com/elixir-lang/elixir/blob/master/lib/elixir >>> /lib/inspect/algebra.ex#L158-L176 >>> >>> Right now it feels this is a very specific use case to justify being >>> added as part of Elixir. >>> >>> >>> >>> *José Valim* >>> www.plataformatec.com.br >>> Skype: jv.ptec >>> Founder and Director of R&D >>> >>> On Fri, Nov 4, 2016 at 1:19 PM, Waldemar Rachwał <[email protected]> >>> wrote: >>> >>>> Hello, >>>> >>>> The rationale behind the proposal is the fact there are cases the >>>> records can be inappropriate. They provide excellent interface, but well, >>>> sometimes the tag atom at first position (index 0) rather harms than helps. >>>> >>>> One such use case I found when dealing with ETS tables. >>>> >>>> ETS entries are tuples. While entries are homogenic, one record >>>> definition which tuple data looks like {:tag, key, field1, ...} seems to be >>>> a good fit and only one has to tell ETS the key is at second position >>>> (index 1). >>>> >>>> However, when it comes to store many tuples of different shapes in one >>>> table, the key itself should differentiate these shapes and the instance >>>> within given shape, something like {:tag, key}, and then the alone :tag >>>> field of a record becomes quite redundant. In such heterogenic ETS tables, >>>> existing records have also their own use: for example to hold singular >>>> entries each with "global" counters as fields. >>>> >>>> Obviously, this is the real use case I encountered. Perhaps there are >>>> others. I have no doubt that generally records, in cases one wants to use >>>> tuples via functional interface, will be default practice. >>>> >>>> I have code ready because I used the stuff earlier from an auxiliary >>>> module. In Elixir the Tuple module and deftuple(p) seem natural, but I was >>>> never good at naming things... >>>> >>>> What do you think? >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "elixir-lang-core" 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/ms >>>> gid/elixir-lang-core/CABR-7m0R8j52Y2r57-hWomJ-nz%2B0R0Q5Q01B >>>> -xm5CAZH0jGHbw%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/elixir-lang-core/CABR-7m0R8j52Y2r57-hWomJ-nz%2B0R0Q5Q01B-xm5CAZH0jGHbw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "elixir-lang-core" 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/ms >>> gid/elixir-lang-core/CAGnRm4LVgRU7j1tAfUS0kY2PUDj44j6D7LUkNi >>> K_tTofsAR4UQ%40mail.gmail.com >>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4LVgRU7j1tAfUS0kY2PUDj44j6D7LUkNiK_tTofsAR4UQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" 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-core/69b83195-e8d6-4866-953c- > 0c561352715a%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/69b83195-e8d6-4866-953c-0c561352715a%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" 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-core/CABR-7m19nmVx-Mdoh6D5_J5xZGGt%2Bx4_1rjKkRWUtesPw_uHHw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
