That article makes it sound like an OOP beast, it is really much simpler
than that.
--
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
Hi Timothy - firstly, thank you for taking the time to read through and
reply. I understand it would have been very easy to read them and move on
thinking 'just a nutter on the mailing list who doesn't really understand
what he's talking about', but I do really appreciate your feedback - thanks
Hey Thomas, thanks for your e-mail :)
On Monday, 29 June 2015 11:25:44 UTC+1, Thomas Heller wrote:
Hey,
interesting approach but I don't like the nesting and manual wiring of
dependencies.
I've found people at both ends of that particular spectrum - some that
won't live with DI, some
Hey James,
the webserver being a client is really very simple. Basically instead of
starting one app you start two. Your actual app and the web-app that
depends on app. One contains your business logic and the other everything
related to translating HTTP to app API calls. app doesn't know
Hey,
interesting approach but I don't like the nesting and manual wiring of
dependencies. I don't quite like that every with-* function remains on the
stack as well, but it shouldn't hurt that much. An uncaught exception will
also take down your entire system, but I guess you'd have a
As promised, have blogged: 'Yo-yo Component - Side by Side
https://github.com/james-henderson/yoyo/blob/master/articles/side-by-side.org
'
Contents:
- Making components
https://github.com/james-henderson/yoyo/blob/master/articles/side-by-side.org#making-components
- Using a
A few bits of feedback after seeing these examples.
Firstly, I'd like to see a more fleshed-out rationale. Currently it sounds
a bit like cargo-culting, e.g. Spring is bad, Component reminds people of
Spring, therefore Component is bad. I'd challenge several parts of that
rationale, but the first
On Wednesday, 24 June 2015 11:17:41 UTC+1, Atamert Ölçgen wrote:
On Tue, Jun 23, 2015 at 11:47 PM, James Henderson ja...@jarohen.me.uk
javascript: wrote:
Hi Atamert - thanks :)
I thought it might be preferable to keep the call to (latch)explicit -
it means that ylet can be used in
Seems like the next step for this would be for me to put together a blog
with an example Component system, and its equivalent Yoyo system?! :)
Should have time for that over the weekend.
James
On Thursday, 25 June 2015 09:05:39 UTC+1, James Henderson wrote:
On Wednesday, 24 June 2015
On Tue, Jun 23, 2015 at 11:47 PM, James Henderson ja...@jarohen.me.uk
wrote:
Hi Atamert - thanks :)
I thought it might be preferable to keep the call to (latch)explicit - it
means that ylet can be used in nested calls, too - for example, to set up
and compose groups of
Hi Atamert - thanks :)
I thought it might be preferable to keep the call to (latch)explicit - it
means that ylet can be used in nested calls, too - for example, to set up
and compose groups of components/sub-systems: (contrived example, though!)
;; (docs for ylet at
Hi James,
Interesting idea. Thanks for sharing.
I think you can simplify this:
(yoyo/run-system!
(fn [latch]
(ylet [db-pool (with-db-pool {...})
:let [server-opts {:handler (make-handler {:db-pool db-pool})
:port 3000}]
web-server
Hi all,
I've just released an early version of 'Yo-yo', a protocol-less, function
composition-based alternative to Component. It's still in its early stages,
so feedback would be very much appreciated!
https://github.com/james-henderson/yoyo
Yo-yo was also an experiment to see what could be
13 matches
Mail list logo
