tag:robotlegs.tenderapp.com,2009-10-18:/discussions/suggestions/74-code-generation-instead-of-reflectionRobotlegs: Discussion 2012-08-27T10:38:39Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/156256622012-04-30T11:04:55Z2012-04-30T11:04:55ZCode generation instead of reflection<div><p>Hi Manfred - interesting stuff!</p>
<p>Swiftsuspenders does its reflection mostly on a just-in-time
basis, and the new DescribeTypeJSON Adobe provided (undocumented,
but it's there) is also faster. So lots of the old overhead
associated with reflection is no longer a big deal.</p>
<p>Code generation is something we'd looked at - well, we've talked
about a mode where you can dump the swiftsuspenders cache as an
object that you just new up and feed it for your release build.
Having said that, Till is pretty clear that the reflection is so
efficient now that it would actually be unnecessary for most use
cases.</p>
<p>I agree that metadata is brittle, and it requires you to alter
your class to have knowledge that should be outside of its domain -
that's why in Robotlegs we support constructor injection which is
metadata-free (though it has limitations around optional
parameters). Having said that, I still use property injection
myself, because it's so much more TDD-friendly.</p>
<p>Till has been on holiday, but I'm sure he'll be interested to
look at what you're doing when he's back in the loop.</p>
<p>Thanks for sharing!</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/156256622012-07-05T12:30:06Z2012-07-05T12:30:06ZCode generation instead of reflection<div><p>Hi Manfred,</p>
<p>thanks for your suggestion - and for the great blog post you
linked<br>
to. And sorry for the late reply, I kind of lost control of my
inbox<br>
for a while.</p>
<p>Much of what follows is an expanded rehashing of what Stray
already<br>
wrote, so sorry for the repetition.</p>
<p>In Swiftsuspenders, I have spent considerable efforts on
getting<br>
reflection to be as fast as possible and on caching the results in
a<br>
sensible way. While I agree that having to use reflection in the
first<br>
place is a drag, I don't think it's that bad in practice with
an<br>
optimized implementation using DescribeTypeJSON where possible.</p>
<p>I do, on the other hand, think that having to use an additional
build<br>
step adds friction for a payoff that's simply not worth it for
the<br>
vast majority of projects. I readily admit that not only is this,
to<br>
some degree, a matter of taste, it also is the wrong tradeoff for
some<br>
projects. Luckily, Swiftsuspenders allows you to provide type<br>
descriptions explicitly, making the injector forego any reflection
of<br>
the affected types. This could easily be used to implement a<br>
build-time step atop of Swiftsuspenders. (In general, I decided
to<br>
leave type description mechanisms out of Swiftsuspenders except
for<br>
those that are already there and sort of provide a base line.)</p>
<p>On another note, I don't agree with your characterization of
[Inject]<br>
tags as binding classes to the DI framework. First of all,
[Inject]<br>
works basically the same across all AS3 DI frameworks, so you can
use<br>
it without tying your code to one of them. Second, there's
nothing<br>
forcing any code to use the [Inject] tags at all. They're merely
a<br>
hint indicating "I except this field to be set from the
outside"<br>
without saying by which means this expectation should be
fulfilled.<br>
Third, at least Swiftsuspenders doesn't even need the [Inject] tag
for<br>
constructors, so except for the reflection overhead, they're
treated<br>
just the same as in your solution. Personally, I like to think of
the<br>
built-in reflection support as a means to let me forego
additional<br>
configuration, while still allowing me to take additional steps
to<br>
make things faster if there's a need for that.</p>
<p>cheers,<br>
till</p></div>Till Schneidereit