As I was saying, just put your factory fns in the same name space than your defrecord and attach a doc string on it...
The sole relative "nicety" of a feature should not be the driving force helping decide if it's worthwhile to implement. You have to consider what exists already. Factory fns are generic, they can return you specialized records according to the context they are called from, they can be impure if you need it, they can implement complex logic if required,... A defrecord constructor would be more or less confined to the specific defrecord it is attached to. Between a generic reusable feature and a narrower one that overlaps, I choose the generic one. Luc > > > I don't think it is "OO-phobia". I think a lot of people here have > > used (several) OO languages and just find the FP way better - or at > > least better for the problems they are solving. > > > > If I am proposing something like state-mutation based OOP, that clearly > conflicts with FP and I will just find another lanugage to work with. FP > itself, which although I am still ajusting to, does not seem like a problem > to me so I sitll have interest to work with it. Again I don't think the > proposal here conflict with FP. It is still FP even with the constructors, > isn't it? > > > > > Also, the proposal here is not "FP vs imperative". The created object is > > > still immutable, and does not violate any FP principles. > > > > > > As of going through FP, after some time, I started see certain benefits > > of > > > FP, but I see nothing saying FP cannot use some ideas in OO. > > > > The question here seems to be whether integrating the factory function > > into the record itself brings sufficient benefits to change the > > language - or whether the record concept and the factory concept > > should remain separate. It seems to me that the latter approach is > > simpler: two distinct concepts that can be combined if needed or used > > separately if desired. > > > > One of Clojure's design goals is simplicity. Keeping functions and > > data separate seems in keeping with that. > > > > > Simplicity is good, only when it is not too simple. Factory functions > denitely have its value, but for more dynamic cases (so you may even create > different record types based on the arguments). For static cases, why > scatter the factory functions here and there with certain name conventions > people may or may not follow? If they both achieve the same functionality, > don't you think grouping them in one place, with fixed naming pattern is > better? I thought OOP people long figured that out. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@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+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail from my ipad! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
