I guess I'm wondering why take Zheng's approach, versus something more 
direct? I'm especially reacting to this: 

One way to look at design using abstract classes (or any language feature 
for that matter) is that it is a programming contract that is strictly 
enforced by the language itself. When we inherit functionality from an 
abstract class, we make a binding contract with the compiler.

…Essentially, it mimics the structure of how abstract classes are defined 
and used in object orientated design through simple use of protocols and 
multimethods.

But why mimic such a contract? Why not just clearly write a contract, using 
a library that is meant to write contracts? I mean, why not use something 
like Typed Clojure? 






On Monday, July 27, 2015 at 1:37:41 PM UTC-4, Lawrence Krubner 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 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.

Reply via email to