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.
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.
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.
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.
thanks for your suggestion - and for the great blog post you linked
to. And sorry for the late reply, I kind of lost control of my inbox
for a while.
Much of what follows is an expanded rehashing of what Stray already
wrote, so sorry for the repetition.
In Swiftsuspenders, I have spent considerable efforts on getting
reflection to be as fast as possible and on caching the results in a
sensible way. While I agree that having to use reflection in the first
place is a drag, I don't think it's that bad in practice with an
optimized implementation using DescribeTypeJSON where possible.
I do, on the other hand, think that having to use an additional build
step adds friction for a payoff that's simply not worth it for the
vast majority of projects. I readily admit that not only is this, to
some degree, a matter of taste, it also is the wrong tradeoff for some
projects. Luckily, Swiftsuspenders allows you to provide type
descriptions explicitly, making the injector forego any reflection of
the affected types. This could easily be used to implement a
build-time step atop of Swiftsuspenders. (In general, I decided to
leave type description mechanisms out of Swiftsuspenders except for
those that are already there and sort of provide a base line.)
On another note, I don't agree with your characterization of [Inject]
tags as binding classes to the DI framework. First of all, [Inject]
works basically the same across all AS3 DI frameworks, so you can use
it without tying your code to one of them. Second, there's nothing
forcing any code to use the [Inject] tags at all. They're merely a
hint indicating "I except this field to be set from the outside"
without saying by which means this expectation should be fulfilled.
Third, at least Swiftsuspenders doesn't even need the [Inject] tag for
constructors, so except for the reflection overhead, they're treated
just the same as in your solution. Personally, I like to think of the
built-in reflection support as a means to let me forego additional
configuration, while still allowing me to take additional steps to
make things faster if there's a need for that.