incubator-s4-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Neumeyer <>
Subject Re: S4 piper object creation design
Date Tue, 15 Nov 2011 15:58:26 GMT
Hi Aron,

Thanks for the feedback. We are definitely open to revisiting the design.
Extending Guice to the app graph is in the TODO list I agree with you that the mixed
model (Guice for the framework but not for the app) doesn't work well.
Ideally, we would like to use Guice for the app graph without requiring the
app developer to use Guice. We thought about creating an app builder layer
on top of Guice, perhaps by extending the Guice Module class. We are
definitely open to this and if you can experiment that would be really

On Tue, Nov 15, 2011 at 6:01 AM, Aron Sogor <> wrote:

> Hi,
> First of congrats, I really like the stuff you have built, I think it is
> one of the cleanest actor models in java, gives me all the reasons not to
> battle an erlang vm. I also really like that you took up Guice and the
> whole idea of ditching the XML config paradigm is sweet!
> What remains strange is that PE and Stream classes are created by the app
> and not via Guice. Here is my concern:
> - In the case of the Stream it is probably not a big deal as a developer I
>  should not be extending or writing my stream classes. (Day #1 I might be
> missing something)
> - In the case of a PE, I would probably like to inject things, from the
> most basic and beloved @Inject Logger, some other custom objects of my own
> to probably even Streams.
> The current model makes this pretty clunky as the app is created by the
> injector but the PE and the Streams are made by the App. I think This could
> overcome with some Tricks with Provider<T> or other helpers. Clearly the is
> a fundamental design choice:
> - Why the App.init() method was created this way? Besides it felt cute, and
> give a sort of DSL to it, is there any other reason?
> I wonder if you up for revisiting this aspect of piper and if you are I
> could help experiment on a github fork, but I would like to understand the
> goals or intentions behind the current idea.
> Aron


Leo Neumeyer (@leoneu)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message