Le 5 août 2012 à 05:33, Warren Lynn <wrn.l...@gmail.com> a écrit :
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, One way to know if it's simple or too simple is probably to stop talking generally, and study concrete examples. As Rich used to say on this ml, come expose problems (in search for a solution), and not solutions (in search for a problem). So, can you expose the current design which causes problem, so that the debate can continue on the merits of this or that solution for your problem ? 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 -- 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
