[erlang-questions] OTP-9649 and further changes

[Yurii Rashkovskii]

> To inform our decision, it would be very interesting to know:
>
> 1) Why are projects using "tuple modules"? Is is because
> the syntax is easy to use or is because of performance or
> some other reason?

I can't speak for everybody, but I can speak of our own use. In
different cases it is obviously a slightly different reason. In our
latest case, it is not an "ease of use" of the syntax, but a whole way
to establish a certain type of operations. This project (not yet
released as open source, but eventually will be) is a relational
database mapper akin to ActiveRecord.

It allows us to map records describing the structute of tables to be
mapped to modules that implement their functionality.

So, suppose we have db_User record:

-record(db_User, { id, email, password }).

and a respective db_User module:

-module(db_User).
-extends(db_model).
-include("models.hrl")

As you can see, this module exports nothing. However, because of
-extends attribute, it will redirect all those missed calls to
db_model module. With tuple calls, the magic happens around there.
When, for example, someone executes User:save(), it gets ultimately
converted to db_model:save(#db_User{}) which can take care of saving
the record. Moreover, db_model:save/1 attempts to call before_save /
after_save callbacks if they are defined in db_User. The way it does
it is fairly simple: it just calls User:callback_name() and if it is
not defined, that call again  goes to the default implementation in
db_model.

Of course it is technically possible to implement all of this without
tuple calls (at an expense of worse syntax), but obviously I'd rather
keep it as is as it works fantastically.

>
> 2) Could the projects use parameterized modules instead?

Some could, I suppose. But a lot of developers (including myself) are
avoiding them because of their many problems, like obscuring functions
arities. Tuple calls don't do that, your module source has functions
the way they eventually will be available in a compiled form.

I suppose you're talking about refined parametrized modules that don't
use tuples and use their own type. In this case the above project will
suffer a damage as it is an important feature of the project to keep
database records as records so that they can be easily matched. Unless
this new type provides a clear alternative to the above, it'll force
us into rewriting the whole thing once tuple calls are removed.

>
> 3) Which are the projects?

I just started collecting the list at
https://github.com/yrashk/9649-consequences — obviously this list is
far from completion and doesn't account for non-opensource projects.

Yurii.