tschneidereit / SwiftSuspenders

NOTE: Find the offical repo at http://github.com/robotlegs/swiftsuspenders
https://github.com/robotlegs/swiftsuspenders
MIT License
280 stars 89 forks source link

Injector still needs an interface ... #88

Open creynders opened 11 years ago

creynders commented 11 years ago

I was just reviewing an example app of working with modules in RL2 and realized that there's a problem now that the Injector no longer implements an interface:

if a submodule uses the injector it gets compiled together with its dependencies into the submodule. Apart from being a little dirty it's a potential problem when you have lots of submodules and you update your shell to use a new version of RL SwiftSuspenders; you'll need to recompile ALL of your submodules. Or am I overlooking something here, is there maybe a reason the injector needs to be compiled into submodules?

tschneidereit commented 11 years ago

That is exactly the oft-mentioned issue that interfaces (purport to) solve. Well, they do solve it, and no, the Injector doesn't need to be compiled into submodules, but the solution is not optimal at all. You still compile in all the interfaces, which can be a non-trivial amount of code, too.

The proper way of handling this is to use -compiler.external-library-path or one of the other, similar, options to exlude everything that's included into the main SWF from also being compiled into the child SWFs. Every project that really does need submodules should certainly be built with a script and automatable, in which case excluding code from the modules is pretty easy.

creynders commented 11 years ago

Ah, I have a major deja vu, probably we discussed (or I listened in on a discussion about) this a while back. Though I agree that interfaces aren't the way to exclude classes, I do think that many people do not know about the compiler options or maybe even aren't aware about the potential problems that could arise from duplicate class definitions. And, again, I agree that "every project that really does need submodules should certainly be built with a script and automatable", but in reality many people will be compiling from Flash Professional which doesn't allow to set any compiler options AFAIK.

Let me put it in another way: Does the disadvantage (as far as there is one) of creating an interface for the Injector outweigh the benefits?

IMO it doesn't. It's a small change and it will automatically keep a lot of people's binaries cleaner.

dotdotcommadot commented 11 years ago

"if a submodule uses the injector it gets compiled together with its dependencies into the submodule" This isn't the case of course, when you use in Flash Builder the option "optimize for application". In this case, only the shell will include libraries that are used both by the shell and by the modules, so you just need to rebuild the shell. (Just sayin')

creynders commented 11 years ago

@dotdotcommadot Yeah, I realize my original post wasn't clear enough. I know it's possible to avoid all of that using the correct compiler options. I'm looking at it from a pretty selfish POV: making RL as optimal as possible while being compilation-environment agnostic and aimed to a very broad spectrum of developers. But maybe this is one of those "we'll just need to educate them" kind of things.

darscan commented 11 years ago

Perhaps it's time to investigate adding the interface to RL instead (like we did in V1)?

darscan commented 11 years ago

From RL2's perspective there is quite a harsh asymmetry here: everything else is injected as an interface.. except the Injector itself - which is pretty weird.