Hey guys, Thanks for the feedback and your very insightful comments.
Yep... this is OO alright =) I realised only after I wrote the article that I was implementing a Lifecycle clone with IRunnable example. However, the concept I am mentioning is much more general than components in terms of its scope: A similar `abstract class` for a reflective functional dispatch mechanism is defined here: https://github.com/zcaudate/iroh/blob/master/src/iroh/types/element.clj and extended by the `concrete classes' here: https://github.com/zcaudate/iroh/tree/master/src/iroh/element In the case of iroh... if I had used strictly multimethods, I would have been very confused. If I had used strictly protocols... well I couldn't for a number of reasons.. but if I did, I would have been even more confused because of the number of subconditions that I had to implement. iroh was the first library that I had built that used this pattern and it was so successful that I've been repeating the process over and over again since. What I wanted to achieve was to have the equivalent of an `abstract class` - the concept of code with abstract functionality that provides a framework for the heavy lifting to be done. `Concrete classes` can just extend aforementioned `abstract class` with minimal code and get all of the benefits. I've used this pattern with great success in many, many times and it provides a counter balance to the functional paradigm in terms of packaging up functionality. Clojure doesn't force us into one paradigm or the other and sometimes it is just more stylish to use the OO paradigm. The whole point of OO, multimethods and protocols is to do polymorphic dispatch, which is just a way to break a large cond statement into pieces that can then also be further extended. Please also note that not all OO frameworks are equal. Java uses a class inheritence approach whereas javascript uses a prototype model. The `abstract container` pattern that I was describing is probably closer to the JS model but to be honest, I don't really know what it is. Ultimately, it adds a middle tier of functionality in systems that have a plugin type mechanism. I'm sure there are equivalent functional contructs... but that was not the point of the pattern. This pattern has been very useful for me; clojure's protocols and multimethods were not enough to do what I needed to do - but combination of the two works wonders =) Since the article, the pattern has been codified here: https://github.com/zcaudate/hara/blob/master/src/hara/extend/abstract.clj#L196 Hope that helps in clarifying the motivation behind the article and the pattern Chris On Monday, July 27, 2015 at 11:42:21 PM UTC+5:30, Colin Yates wrote: > > I think his last sentence gives you the answer: > > "A warm shoutout to Tushar, Lyndon, Dean, Alan, Hank, Derek, and all the > guys at clj-melb that gave feedback and helped flesh out this rehash of *OO > design*.” (my emphasis) > > He wanted an OO approach and has implemented one; specifically behaviour > and state coupled together. I think neither Typed Clojure nor Contracts > would have achieved this guy’s goal as they are about enforcing a contract > (either the shape of data or effects of a fn) in the ‘functional’ paradigm; > this guy clearly wanted something in the OO paradigm. > > Is there a ‘functional’ implementation which gives the same benefits; > sure, but that isn’t what he wanted. Are there a bunch of ‘upgrades’ that I > am sure we could all apply; sure, but again it seems like he was setting > out with a very specific goal in mind and has achieved that. > > On 27 Jul 2015, at 18:37, Lawrence Krubner <lawr...@rollioforce.com > <javascript:>> wrote: > > I have a question about this: > > "Servers that are running on a particular port can be tracked and stopped. > I have to say, this was the feature that I wanted the most, which motivated > the framework's design. The annoying thing about development in emacs is > that I have to be careful of not losing the reference to the server. Since > there was no way of stopping it unless the repl is restarted. I wanted to > implement a registery for references to running servers to be saved." > > http://z.caudate.me/the-abstract-container-pattern/ > > I have the impression that he's going over the same territory as that > covered by Stuart Sierra, though Zheng doesn't mention "Component" nor > "Sierra". But he offers this as an example of what he's after: > > (defprotocol IRunnable (start! [system]) (stop! [system]) (restart! > [system]) (started? [system]) (stopped? [system])) > > That much seems similar to Sierra's system. Zheng seems to add an > additional layer by simulating an abstract class above his protocols. As he > says: > > > - A single deftype acts as the *abstract container*, extending one or > more protocols > - A set of methods defined through defmulti that is used within the > deftype form act as *abstract methods* > - The *abstract methods* all dispatch on map keys (usually :type). > > > I am curious if others have found this useful? > > Most of the people who work with Clojure have backgrounds with Object > Oriented Programming, so that paradigm sometimes seems natural, or at least > familiar. I often think these designs are more verbose than they need to > be, but I am curious how others feel. > > > > > > > > > > > -- > 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 <javascript:> > 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 <javascript:> > 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 <javascript:>. > For more options, visit https://groups.google.com/d/optout. > > > -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
