Thank you for the comments, lots of good points.
=> IRegistryObject <=
> (2) IRegistryObject is odd - can you not split this into two
> interfaces that we would recommend are being used whenever objects
> need to be initialized, or disposed?
Yes, this makes sense, let's split it into IDisposable and IInitializable.
On the subject of using reflection instead of the IRegistryObject:
+ it would remove dependency on container code [as pointed by Heiko]
- it generally makes code harder to read [as pointed by Gunnar]
Both are good arguments. I think that if we put IDisposable and
IInitializable into "org.eclipse.equinox.common" it might help with the
arguments of having container-dependent code.
=> Existing DI frameworks <=
> What about existing dependency injection frameworks? ... Wouldn't it
> be good if clients could specify which dependency injection mechanism
> they would like to be used?
One problem with the current DI frameworks is that they are complicated to
use (some are better than others). Moreover, frameworks are different
enough in the injection styles, bootstrapping, multiplicity and
concurrency support that if we try to provide a common meta-DI framework,
it will end up being something really complicated. Which would be the
opposite of the intention here - providing a simple to use mechanism for
simple everyday tasks.
I did play a bit with the idea of having a DI framework added on top of
the registry. On a design level that seemed to be overdone as the
extension registry in essence is a DI framework that injects data from
extensions into extension points. On an implementation level, from about
half dozen open-source frameworks I looked at, none seemed to be a good
fit. There were multiple reasons, most important being ease of use,
support for pre-1.5 VMs, ability to work with OSGi bundles as containers,
and active community.
So, interesting idea, but I am not sure how practical it is.
> In Riena we have a simple approach for injecting extensions into target
objects. This is similar to DI but not for services but for data.
Yes, thank you, I'll look into this.
=> Single context object <=
> I don't like that clients cannot provide more than just one single
> "context" object.
Good point. I did this for simplicity as having only one argument
eliminates the need to match constructor arguments. If we were to support
multiple arguments we'd have to add a new construct to the extension point
schema - something like
<constructor>
<argument position = "1" name = "name_of
the_attribute_from_plugin_xml"/>
<argument position = "2" name = "name_of
the_attribute_from_plugin_xml"/>
...
</constructor>
This is probably worth supporting as an option.
=> Annotations and VM support <=
Annotations would be really nice to use. As an example take be the topic
above ("single context object"): annotations could have been used to tie
constructor arguments to the XML attributes.
However, Eclipse SDK runs on 1.4 and the position of the extension
registry in the Eclipse stack does not give us much freedom. We'll have to
support pre-1.5 VMs at least in the 3.x stream, there is no choice. As
such any functionality based on annotations would have to be optional.
=> Timeline; E4 <=
> Is there any progress in relation to e4? I understand that this is a
work item on the e4 list.
I think that sometime before the end of 3.5M6 we'll look at what's
available and how stable that code is. Personally, I'd expect some of the
enhancements to get into 3.5, but not all. As for the relation to E4's
dependency injection item - yes, I'd consider this to be one of the
aspects of it. There are two mechanisms in Eclipse that could use improved
DI support: extension registry and OSGi services. I don't think that
either one of them is going to go away any time soon. Rather both have
their roles. For the dependency injection:
- the extension registry: while it might not look like a conventional DI
framework, in spirit it is very similar. The functionality gets obscured
by registry artifacts as pieces that gets injected are
IConfigurationElements / IExtensions. With this enhancement the actual
Java typed objects will be injected using method/field injection; and an
optional "context" elements will be injected via constructors.
- for the OSGi services I believe that Declarative Services would be the
best fit in terms of adding DI mechanism. From the mailing lists it seems
that there is a fair amount of activity both on PDE tooling support for DS
and on the DS itself.
Thanks,
Oleg
_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev
