James: For sure. To be honest, I haven’t really thought too much about best
practices. The code just naturally evolved in this way. Let me have a think
about this over the weekend and come up with something.
Lawrence: I see what you are saying… and again, I need some time to think
about the
If I understood your original article, you were saying something that
amounted to these 3 assertions:
1.) to future-proof our code against changes, and to avoid being verbose,
we need polymorphism.
2.) we need some way to establish constraints (contracts) on that
polymorphism, or else it will
On 29 July 2015 at 01:07, zcaudate wrote:
> The example in the article is probably the smallest example I can come up
> with.
>
> http://z.caudate.me/the-abstract-container-pattern
>
> The code for the concrete implementations speaks for itself I think, it is
> about 10 lines to hook in jetty and
The example in the article is probably the smallest example I can come up
with.
http://z.caudate.me/the-abstract-container-pattern
The code for the concrete implementations speaks for itself I think, it is
about 10 lines to hook in jetty and http-kit to the framework.
if we think about how muc
What are the benefits of designing an "abstract class" in this way,
compared to, say, using a protocol and normal functions? Could you provide
a small example?
- James
On 28 July 2015 at 10:09, zcaudate wrote:
> Hey guys,
>
> Thanks for the feedback and your very insightful comments.
>
> Yep...
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 it
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
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. W
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
