Generate .hrl file with record definitions

[burbas]

Hi,

I've been working on a new feature for boss_db that generates a .hrl-file containing the record definitions for a specific model. This is so we can support default values.

Example:

-module(user, [
    Id,
    Username :: string(),
    IsAdmin = false :: boolean(),
    IsSuperAdmin = false :: boolean(),
    ...a lot of stupid variables...
]).

This model will result in a .hrl-file looking like this

-record(user, {
    id,
    username :: string(),
    is_admin = false :: boolean(),
    is_super_admin = false :: boolean(),
    ...more definitions...
}).

So lets say that we want to create a user in one of our files:

-include("priv/user.hrl").

my_func() ->
    User = #user{username = "Burbas"},
    %% User will be set to {user, id, "Burbas", false, false, ...}
    User:save().

What do others think about this? Is this something worth to pursue?

[choptastic]

Hi Niclas,

This is similar in nature to the direction I'd like to take boss_db, in the effort/attempt to phase out some of the compiler magic.

Though one of the common problems is presented in your snippet (though I realize it's not critical to your example): Erlang already has a "user" module, and as such there are natural conflicts there, and as such a user model has issues being recompiled automatically.

I was thinking perhaps a safer way to go about it would be to use Erlang's $handle_undefined_function option, which could help us get around some of those limitations

That said, the record approach isn't bad, and does let us use records, which can be nice if you didn't want to set/get with setters and getters, and also enables the use of pattern matching.

HOWEVER, with maps being recently introduced, I wonder if the flexibility of maps might be more suited to something like this.

I'm honestly very on the fence about it all. Maps, however, could not be used in the clever way records can be used in that "overloaded" manner.

-Jesse

On Mon, Aug 11, 2014 at 3:25 PM, Niclas Axelsson [email protected] wrote:

Hi,

I've been working on a new feature for boss_db that generates a .hrl-file containing the record definitions for a specific model. This is so we can support default values.

Example:

-module(user, [ Id, Username :: string(), IsAdmin = false :: boolean(), IsSuperAdmin = false :: boolean(), ...a lot of stupid variables... ]).

This model will result in a .hrl-file looking like this

-record(user, { id, username :: string(), is_admin = false :: boolean(), is_super_admin = false :: boolean(), ...more definitions... }).

So lets say that we want to create a user in one of our files:

-include("priv/user.hrl").

my_func() -> User = #user{username = "Burbas"}, %% User will be set to {user, id, "Burbas", false, false, ...} User:save().

What do others think about this? Is this something worth to pursue?

— Reply to this email directly or view it on GitHub https://github.com/ChicagoBoss/boss_db/issues/194.

Jesse Gumm Owner, Sigma Star Systems 414.940.4866 || sigma-star.com || @jessegumm

[burbas]

Hi Jesse,

I know that the "user"-module already exist and my example therefore would fail if trying to compile it :-). It was just for demonstration purpose.

Can you explain a bit further how you want to use the $handle_undefined_function option? I'm unfamiliar with it and did not find much info about it when googling.

I've also looked at how one could use maps in boss_db, but don't like the thought of removing the clever things you get when using records the way boss_db does. The only positive thing with using maps in boss_db is that you'll get a mutable object that can be updated.

[davidw]

On a tangent, it would be really cool, in a user-friendly way, to make CB fail to compile the 'user' module in a very friendly way.