tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/860-optional-injectionRobotlegs: Discussion 2012-04-11T11:04:16Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/148610532012-03-29T08:51:28Z2012-03-29T08:51:29ZOptional injection<div><p>I haven't seen anything in the documentation so I'm guessing the
answer is probably no but is there and way specify an dependancy as
optional via metadata or otherwise?</p>
<p>i.e. [Inject (optional=true)]</p>
<p>Would it be considered a good idea even if it was?</p>
<p>My specific use case is:<br>
I'm using the SignalCommandMap variant which injects the signal
payloads automagically into my command. It is valid in some cases
however for the payload to be null which unfortunately throws a
runtime error in the injector as it is missing an object to fill
the rule.</p>
<p>Thanks in advance,<br>
Tim</p></div>Timtag:robotlegs.tenderapp.com,2009-10-18:Comment/148610532012-03-29T09:09:46Z2012-03-29T09:09:46ZOptional injection<div><p>Hi Tim,</p>
<p>support for optional injections has only been introduced in<br>
Swiftsuspenders 2, which isn't officially supported in Robotlegs
1.</p>
<p>That being said, you might want to check out my special build
of<br>
Robotlegs 1.5.2 including the current beta release of
Swiftsuspenders<br>
2 here:<br>
<a href=
"https://github.com/tschneidereit/robotlegs/downloads">https://github.com/tschneidereit/robotlegs/downloads</a></p>
<p>Based on all tests and feedback, this build should be fully
compatible<br>
with the official Robotlegs 1.5.2 while giving you access to<br>
Swiftsuspenders 2.</p>
<p>hope that helps,<br>
till</p></div>Till Schneidereittag:robotlegs.tenderapp.com,2009-10-18:Comment/148610532012-03-29T09:39:36Z2012-03-29T09:39:37ZOptional injection<div><p>Hey Till,</p>
<p>Thanks for the quick response. Will definitely check it out and
let you know how I get on.</p>
<p>Upon rereading my original post it would appear that I am
illiterate... so many typos.</p></div>Timtag:robotlegs.tenderapp.com,2009-10-18:Comment/148610532012-03-29T09:49:28Z2012-03-29T09:49:28ZOptional injection<div><p>He, no worries: I understood what you were asking - and that's
what<br>
counts, right?</p></div>Till Schneidereittag:robotlegs.tenderapp.com,2009-10-18:Comment/148610532012-03-29T10:22:16Z2012-03-29T10:22:16ZOptional injection<div><p>Hey Tim,</p>
<p>the other alternative, if using Swiftsuspenders2 doesn't work
out, is to use the NullObject pattern - where you make a specific
class, extending the required value, which stands in for null
values - the intent of that pattern being to avoid null-pointer /
null-check errors.</p>
<p>Generally I'd say that's a better option in this scenario anyway
- because "NullUser" shows future coders (including yourself) that
you really did intend this situation. It also means that a genuine
null error won't be swallowed.</p>
<p>So - tread with care in creating optional injections - if
there's ever likely to be a scenario where you could be swallowing
a meaningful error, take the NullObject route instead.</p>
<p>For me, optional injections are more appropriate for scenarios
like commands inside modules that may or may not be running in a
certain shell, and therefore may or may not have access to a logger
etc. Of course it would usually still be better to explicitly check
for and provide a null implementation of the logger... but I'm sure
there are use cases where it's very appropriate, but my current
thinking is that they would be less dynamic conditions - your
scenario being the highly dynamic end of things.</p>
<p>Having said all that, until we've all had a few months to bang
up against the pros and cons of using optional injections, and
actually feel the joy and pain, I'm only extrapolating (which is
just a fancy name for guessing).</p>
<p>ymmv etc,</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/148610532012-03-29T14:29:14Z2012-03-29T14:29:15ZOptional injection<div><p>Stray, Till thanks a lot for the prompt and well thought out
responses.</p>
<p>Till, your SwiftSuspenders 2 build works like a charm although
the runtime error stopped occurring before I actually updated the
metadata tag with the new optional parameter which may be cause for
concern, perhaps the injection is a little more forgiving in
2.0</p>
<p>Stray, you make some good points. The NullObject pattern isn't
something I have used in anger before but will definitely consider
it in future as I do favour an explicit statement of intent
wherever possible.</p>
<p>Thanks,<br>
Tim</p></div>Timtag:robotlegs.tenderapp.com,2009-10-18:Comment/148610532012-03-29T15:48:42Z2012-03-29T15:48:42ZOptional injection<div><p>Thanks for the feedback, Tim.</p>
<p>I'll look into Swiftsuspenders 2 not throwing an error even
without<br>
the 'optional' flag: That should still happen.</p>
<p>And I agree with Stray: a NullObject is the better solution
which I<br>
unfortunately forgot to mention in my first reply.</p></div>Till Schneidereittag:robotlegs.tenderapp.com,2009-10-18:Comment/148610532012-03-29T15:58:23Z2012-03-29T15:58:23ZOptional injection<div><p>Thanks Till,</p>
<p>It does appear to be specifically related to the Signal payload
injection,<br>
error throwing on regular properties functions as expected.</p></div>Tim Drewtag:robotlegs.tenderapp.com,2009-10-18:Comment/148610532012-03-29T16:00:58Z2012-03-29T16:00:58ZOptional injection<div><p>Ah, thanks for that info, that's interesting indeed.</p>
<p>Makes me guess that nothing's wrong in Swiftsuspenders there: it
now<br>
accepts <code>null</code> as a valid mapping value and didn't
before. Seems like<br>
the Signals extension maps null if it doesn't find a "real"
value.</p></div>Till Schneidereit