instanciate non-mapped classes

[hvilela]

I would like to see an flag on the injector to force it to instanciate non-mapped classes to avoid long lists of simple classes mapping. So, we could do:

injector.instanciateNonMappedClasses = true;

insted of:

injector.mapClass(ClassA, ClassA);
injector.mapClass(ClassB, ClassB);
injector.mapClass(ClassC, ClassC);
...

[tschneidereit]

This will be supported in a slightly different fashion in Swiftsuspenders 2. Instead of just instantiating unmapped classes, it will be possible to set a default dependency provider that will be invoked after no specific provider has been found for a dependency. This provider can be used to simply create an instance of the requested class.

[darscan]

How is this looking?

[tschneidereit]

Right, the default provider. I remember having some problem with it, but I'll look into that once again.

[darscan]

Am I correct that at the moment one can do this:

injector.getInstance(NonMappedClass);

and a new instance will simply be created. Whereas, if a container-constructed class has a dependency on such a non-mapped class an error will be thrown?

Symmetry!

[tschneidereit]

Gah!

Yes, you are correct. And yes: Symmetry!

Maybe this even ties in nicely with my strongly held belief that interfaces should only ever be created if there are more than one implementation of something. Changing the injector to just inject new instances of a requested class if they're not mapped would mean that a mapping only ever needs to be created if an interface is requested, too - which seems nice.

On the other hand, I remember you wanting singleton mappings to be the default (still not gonna happen!), indicating that for a large number of use cases, the mapping would still be required.

[tschneidereit]

@darscan recently made a pretty good point about there being a nice symmetry between Injector#getInstance() returning new instances for unmapped types and the injector just instantiating unmapped classes when requested dependencies. Hence, this is how it works, now.

[Stray]

Sorry guys, I missed this.

"I forgot to map this" is a mistake I make frequently. In RL1 that's cool, the injector has my back. But Silent Fails are a nightmare to debug.

I suspect the symmetry isn't real - the process you're entering into is different. Actually, I think it should be the other way around. These processes should be less symmetrical. If anything I think how it was before was a feature, not a bug. "Make this according to the rules I have given you" is different from "Make this".

Initially I thought that as I like interfaces I wouldn't see these silent fails anyway, but actually this is a big issue around the signal command map - if the command expects a value to be injected and it isn't passed in the signal then that's unlikely to be something that you don't want to be told about.

I know folk have complained that they can't pass null in a Signal before, but I think that's a feature not a problem, and we could have a generic NullInjectableObject that the injector doesn't choke on for those situations where folk want to do it deliberately and can't be bothered to implement their own NullObjects [conditionals be damned but hey ho].

So, I'd prefer the injector to protect me when I've forgotten to map than be all-forgiving of missing mappings for concrete classes.

If I just want to use the injector as a factory, newing up stuff as it needs to to get the job done, and not holding on to those values, there could be an explicit method for that...

injector.newThisShitUp(UnmappedClassWithUnmappedDependencies);

However - the original poster's suggestion, that this could be a flag on the injector, sounds workable to me as well (without considering how Till implements it). At least it lets me opt out of the silent fails, and we could specify that this mode is not compatible with use of signal/message-passing-object based commands.

It's also not advisable to have this flexibility when using with guards/hooks on the mediator map, where the concrete view injection might just quietly new up a view in your hook rather than help you diagnose a problem. I'm thinking of when people inject a view into a guard or hook against a (super or sub) type that they didn't specify in the TypeMatcher. I was relying on the injector to help them diagnose this problem.

On the interfaces issue: it's absolutely not that I don't believe the same as you Till - I believe you're exactly correct about the preferred situation in theory, but that without duck-typed interfaces it's not deliverable in AS3, unless we give up the nice DSLs and are prepared to make modular compilation much more cumbersome. Personally, I think the DSL alone is worth the hit of having to have interfaces, even without considering how much more difficult modular development becomes without them.

[tschneidereit]

So I'm mostly convinced - thanks for the clear arguments against auto-instantiation, @Stray.

I'll leave this open and wait for other comments for a bit, but if nothing new comes up, I'll probably implement the flag-based solution. Both because it's easiest and because it seems closest to satisfying demand while preventing problems.

@Stray, so as not to smear that discussion all over the place, could you add yet another explanation of why class-interface dualism is required for the base case in DSLs to the mailing list discussion? Sorry for being so dense, but I honestly still don't get that point. (I get, but don't agree with, the point about increased difficulty of modular development.)

[MindScriptAct]

Regarding this question I would suggest to follow The zen of python:

Explicit is better than implicit.
Errors should never pass silently.
There should be one-- and preferably only one --obvious way to do it

(witch I did in my mvc implementation and it works like a charm.)

just my two cents...

[tschneidereit]

There should be one-- and preferably only one --obvious way to do it

What's the one obvious way to do it? And what exactly is it in this case?

[MindScriptAct]

proxyMap.map(new MyProxy(), IMyOptionalProxyInterface, "optionalName");

If I need a proxy... I just map it. If I need it only sometimes... I have commands to handle that.
I hate any automation regarding proxy classes, as they form a base of application.

[tschneidereit]

I'm not sure I can follow. What are "proxy classes" in your framework
and how do they relate to automatically instantiating non-mapped
concrete classes when they're requested for injection in
Swiftsuspenders?

[MindScriptAct]

Hm... Good point.

In both cases injection is used... but we use different approaches.

Your approach is universal and generic, mine is tied to framework and does what I need and only what I need.(to make it run fast and avoid bloated implementation..)

Ignore me.