Would a custom constructor for records be a silly idea?

247 views
Skip to first unread message

juh...@gmail.com

unread,
Dec 27, 2015, 12:21:45 PM12/27/15
to Clojure
I'm wondering about the record usage where a record would have relations between its fields. This would be best explained with the following example:

user=> (defrecord Time [minutes seconds])

user.Time

user=> (->Time 0 59)

#user.Time{:minutes 0, :seconds 59}

user=> (update (->Time 0 59) :seconds inc)

#user.Time{:minutes 0, :seconds 60}


It's not very nice since 60 seconds is not really a valid value. If it would be possible to define so that


user=> (Time. 0 60)
#user.Time{:minutes 1, :seconds 0}


then if I'm reading emit-defrecord correctly, assoc and therefore update etc. would work as expected here. Would this be semantically against principles of record or could some kind of structure to modify the fields while creating a new instance of a record be considered as part of Clojure?



Juho


Mimmo Cosenza

unread,
Dec 27, 2015, 12:37:17 PM12/27/15
to clo...@googlegroups.com
A custum constructor (aka factory function) is even considered idiomatic


HIH

mimmo


--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

juh...@gmail.com

unread,
Dec 27, 2015, 3:01:31 PM12/27/15
to Clojure
Hi,

Thank you for your help, but actually a factory function is not quite what I meant.

My problem is that when I call assoc for the record it will create a new record calling the class constructor directly, not the factory function. So even if I add additional checks to the factory function and make sure that is the only public function used to create records of that type, it's still possible to assoc/update/whatever the record and get around the checks. What I would like to override is the actual Java (or JavaScript) constructor used to initialize a new record. That way it would be called even when creating new records of that type from inside the record itself.

For reference about where the internal clones are created, see:


The best way to get the results I would like, seems to be to basically duplicate the whole defrecord code, which would feel very silly. I'm interested in knowing is there another way to make sure that a record always satisfies some rules (and is modified to satisfy those if it doesn't).


Juho

Francis Avila

unread,
Dec 27, 2015, 4:50:03 PM12/27/15
to Clojure
In clojurescript you can just "override" the necessary protocols inline in the defrecord. You will get a warning, but everything will work. You can silence the warning by using extend-type instead of an inline implementation.

In clojure, doing this will give you a compile-time error, meaning you have to reimplement all the functionality of a defrecord using deftype, even for protocols you do not actually want to override.

The Potemkin library has some macros to make this kind of thing less tedious, I recommend taking a look: https://github.com/ztellman/potemkin

juh...@gmail.com

unread,
Dec 27, 2015, 6:50:26 PM12/27/15
to Clojure
On Sunday, December 27, 2015 at 11:50:03 PM UTC+2, Francis Avila wrote:
> In clojurescript you can just "override" the necessary protocols inline in the defrecord. You will get a warning, but everything will work. You can silence the warning by using extend-type instead of an inline implementation.

Hmm, I have to try out that extend-type trick to silence the warnings, although using defrecord for clojurescript and not for clojure would feel awkward as well.

> In clojure, doing this will give you a compile-time error, meaning you have to reimplement all the functionality of a defrecord using deftype, even for protocols you do not actually want to override.
>
> The Potemkin library has some macros to make this kind of thing less tedious, I recommend taking a look: https://github.com/ztellman/potemkin

Oh, I'd had a look at Potemkin before in other context, but had forgotten it also has def-map-type which helps. I'll go look there for inspiration. In any case it looks like custom deftype and implementing map functionality on top of that would be the way to go.

Thanks a lot for your help in clearing out things. Would still hope for the records to be a bit more extensible, having a typed map that can implement protocols and avoids lookups for fields is nice, but doesn't really bring that much benefits over plain maps and functions IMHO.

Reply all
Reply to author
Forward
0 new messages