> Injecting a null value feels odd. What do you think about providing
> something like:
>
> public interface NullableSymbol<T> {While I understand the sentiment, what do you gain? You still have to do the null check to use the value. Specify required=false tells you to expect null. I suppose that we could instead add support for @Nullable http://code.google.com/p/jsr-305/source/browse/trunk/ri/src/main/java/javax/annotation/Nullable.java?r=24 On Sep 18, 2011 4:44 AM, "Igor Drobiazko" <igor.drobia...@gmail.com> wrote: > > On Fri, Sep 16, 2011 at 4:28 PM, Josh Canfield <joshcanfi...@gmail.com >wrote: > > > > So what gets injected if the symbol isn't defined? tapestry-ioc > > > already throws an exception if a symbol does not exist. > > > > I would expect null if it's not required and not present. > > > > Injecting a null value feels odd. What do you think about providing > something like: > > public interface NullableSymbol<T> { > T get(); > boolean exists(); > } > > which would be used to inject a nullable symbol value instead of the > symbol's target type. > > So, instead of: > > @Symbol(value="foo-symbol", required="false") > private String foo; > > you would use: > > @Symbol("foo-symbol") > private NullableSymbol<String> foo; > > > > > Although we are not methodical about it, there is an intuitive split > > > between service interfaces that other code uses vs. interfaces that > > > user code implementes. SymbolSource would fall into the former camp > > > (user code does invoke it, but does not implement it), so adding a new > > > findXXX method would be reasonable, and I think, better than > > > introducing an exception. > > > > True, the service is probably not implemented by anyone so adding the > > method could be added easily enough. > > > > If there is no objections I'll add this along with the field to the > > annotation. > > > > I think it's absolutely ok to add new methods to SymbolSource interface. > > > > > On Mon, Sep 12, 2011 at 3:27 PM, Howard Lewis Ship <hls...@gmail.com> > > wrote: > > > So what gets injected if the symbol isn't defined? tapestry-ioc > > > already throws an exception if a symbol does not exist. > > > > > > Although we are not methodical about it, there is an intuitive split > > > between service interfaces that other code uses vs. interfaces that > > > user code implementes. SymbolSource would fall into the former camp > > > (user code does invoke it, but does not implement it), so adding a new > > > findXXX method would be reasonable, and I think, better than > > > introducing an exception. > > > > > > On Mon, Sep 12, 2011 at 2:01 PM, Josh Canfield <joshcanfi...@gmail.com > > > wrote: > > >> This issue is in line with what I want to do: > > >> https://issues.apache.org/jira/browse/TAP5-1531 > > >> > > >> In order to preserve the interface I would add a specific runtime > > >> exception "SymbolNotFoundException" instead of adding a method to the > > >> SymbolSource interface. > > >> > > >> On Mon, Sep 12, 2011 at 1:51 PM, Josh Canfield < joshcanfi...@gmail.com> > > wrote: > > >>> I don't always want to provide default values for symbols used > > >>> throughout my application, especially when used to configure third > > >>> party applications which provide their own defaults. I'd rather be > > >>> able to detect null values. > > >>> > > >>> Any objections to adding a "required" attribute to @Value and @Symbol? > > >>> > > >>> Josh > > >>> > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > > >> For additional commands, e-mail: dev-h...@tapestry.apache.org > > >> > > >> > > > > > > > > > > > > -- > > > Howard M. Lewis Ship > > > > > > Creator of Apache Tapestry > > > > > > The source for Tapestry training, mentoring and support. Contact me to > > > learn how I can get you up and productive in Tapestry fast! > > > > > > (971) 678-5210 > > > http://howardlewisship.com > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > > > For additional commands, e-mail: dev-h...@tapestry.apache.org > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > > For additional commands, e-mail: dev-h...@tapestry.apache.org > > > > > > > -- > Best regards, > > Igor Drobiazko > http://tapestry5.de
