Support defrecordp #553

Closed
josevalim opened this Issue Oct 18, 2012 · 12 comments

Projects

None yet

4 participants

@josevalim
Member

The idea of defopaque is to support erlang like records, which are only available at compilation time and are not meant to be exported. Better name suggestions are also welcome. :)

This is already implemented, but it is a hidden feature. Here is an example:

https://github.com/josevalim/dynamo/blob/master/lib/dynamo/cowboy/http.ex#L11

I believe @khia is using it as well.

@devinus
devinus commented Oct 20, 2012

Reminds me of defstruct in Clojure vs defrecord.

@yrashk
yrashk commented Oct 30, 2012

defopaque will mentally clash with @opaque (and Kernel.Typespec.defopaque?). Otherwise an interesting idea.

@josevalim
Member

Agreed.

Maybe defrecordp? After all it is a record, but it is private to the current module.

@yrashk
yrashk commented Oct 30, 2012

defrecordp is an interesting suggestion

@josevalim
Member

Just now I saw @devinus feedback. It is indeed similar to Clojure's since this proposal would be a stripped down version of defrecord. However, defstruct does not imply it is "private" or limited to the current scope.

@khia
khia commented Oct 30, 2012

+1 for defrecordp

@devinus
devinus commented Oct 31, 2012

My only problem with defrecordp is that they don't behave like defrecords at all. Seems weird to just call it a private record...

@josevalim
Member

My only problem with defrecordp is that they don't behave like defrecords at all.

Agreed @devinus. This is my concern too.

Seems weird to just call it a private record...

This doesn't bother me much if we consider a record to be a tagged tuple (and it is what is_record checks for). The private means that it is meant to be manipulated inside the current module and only in there.

As you said, my main concern is about the APIs being very different.

@devinus
devinus commented Nov 1, 2012

In fact, I can imagine a defrecordp that actually is a defrecord private to the module.

@josevalim josevalim closed this Nov 10, 2012
@devinus
devinus commented Nov 11, 2012

I think this was a mistake calling it defrecordp. It doesn't share any of the same characteristics of a defrecord and like I said, I can imagine a future in which we'd want a real private defrecord.

@yrashk
yrashk commented Nov 11, 2012

Do you think defstruct is better?

On Sat, Nov 10, 2012 at 4:35 PM, Devin Torres notifications@github.comwrote:

I think this was a mistake calling it defrecordp. It doesn't share any of
the same characteristics of a defrecord and like I said, I can imagine a
future in which we'd want a real private defrecord.


Reply to this email directly or view it on GitHubhttps://github.com/elixir-lang/elixir/issues/553#issuecomment-10261779.

@josevalim
Member

@devinus I have done both patches, one with defstruct and another with defrecordp and I have decided to go with the latter because at the end of the day you still have a record (a tagged tuple) but just a different API to work with it. If we had defstruct, we would probably require a is_struct function, support Struct in protocols and saying it is a record in such cases did not feel correct. Having two different entities for tagged tuples does not feel correct either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment