Home » Eclipse Projects » Eclipse 4 » DI Question
| |
| Re: DI Question [message #525058 is a reply to message #525043] |
Mon, 05 April 2010 15:52   |
 Max Bureck
Messages: 72
Registered: July 2009 |
Member |
|
|
Am 05.04.2010 16:25, schrieb Paul Webster:
> Max Bureck wrote:
>> Hello,
>>
>> I was browsing through the EclipseCon e4 slides and found this piece
>> of code:
>>
>> @Inject
>> private void setSelection(@Optional
>> @Named(IServiceConstants.SELECTION) Contact contact) {
>> //…
>> }
>>
>> Why do you use @Named with string constants defined in an interface
>
> @Named is defined in JSR 330 exactly for this purpose.
And @Qualifier is defined in JSR 330 exactly for the purpose to provide
custom Qualifiers. What you do is using a String in @Named, taking away
type-safety and then re-add it by using constants.
It may be more time-consuming to provide a bunch of
qualifier-annotations, but every piece of code that uses the annotations
will be easier to read.
> The constants
> (describing data) that are available from the IEclipseContext are very
> dynamic and many are provided at runtime (SELECTION is data that we know
> will be provided by the framework, but many other pieces of data or
> services are much more dynamic).
I'm Sorry, you lost me here. Why are the constants dynamic and how does
this affect the question @Named vs. qualifiers?
> Using the interface constants is just a way to publish common strings,
> instead of making everybody type out "activeContexts" ... I don't know
> what your dude has against them, but it's a pretty common practice.
> What's his alternative?
The alternatives would be (again suggested by Joshua Bloch, great book BTW)
1. If the constants are tied to specific classes or interfaces, define
them in that classes/interfaces.
2. If 1. is not possible (which seems to be the case for SELECTION)
define the constants in a noninstantiable class (using a private
constructor) instead of in an interface.
The problem with Interfaces is, that the users can implement them. You
may argue that only a moron would do this, but still: It's possible.
This is a problem for the user who implemented it (maybe accidentally),
because it leaks implementation detail and if this is a
public(/exported) class it is part of the API of that class (and
subclasses), so the class has to implement the interface for all time
(or to the next version change breaking backwards compatibility ;-))
This may seem a bit academic, but if you prefer clean code you should
take the advice.
> That's not to say Qualifier can't be supported, but I'm not sure how I
> would impose compile time semantics on information that is decided at
> runtime.
If qualifier-support would drastically decreases performance, you've got
a good reason not to use them, indeed.
Regards,
Max
|
|
|
| Re: DI Question [message #525707 is a reply to message #525058] |
Wed, 07 April 2010 14:13 |
|
Max Bureck wrote:
>
> And @Qualifier is defined in JSR 330 exactly for the purpose to provide
> custom Qualifiers. What you do is using a String in @Named, taking away
> type-safety and then re-add it by using constants.
The short answer is we don't currently support that. I don't see
anything wrong with supporting it (since both annotations are in the
spec both are there to be used).
>> The constants
>> (describing data) that are available from the IEclipseContext are very
>> dynamic and many are provided at runtime (SELECTION is data that we know
>> will be provided by the framework, but many other pieces of data or
>> services are much more dynamic).
>
> I'm Sorry, you lost me here. Why are the constants dynamic and how does
> this affect the question @Named vs. qualifiers?
The keys available for injection are dynamic. Some, like "selection",
will probably always be there. Some, like "activeContexts", will be
provided if that service is available (coming from the deployed
plugins). Others will be provided by the model or the contributing
parts themselves. @Named is an important part of our story.
> The alternatives would be (again suggested by Joshua Bloch, great book BTW)
> 1. If the constants are tied to specific classes or interfaces, define
> them in that classes/interfaces.
Ah, I agree. With one or two exceptions, the constants should be
defined by the service providing them. i.e.
EContextService.ACTIVE_CONTEXTS, ESelectionService.SELECTION, etc. That
some of them are in service constants was a convenience, and their use
from the common interface still has to be reviewed before we ship.
> 2. If 1. is not possible (which seems to be the case for SELECTION)
> define the constants in a noninstantiable class (using a private
> constructor) instead of in an interface.
In eclipse constants are published with an interface, and then the
interface is marked @noimplement, @noextend. A non-instantiable class
would also be acceptable, but the platform standard is the interface.
>
> This may seem a bit academic, but if you prefer clean code you should
> take the advice.
well, if you put it that way then I *don't* prefer clean code and I
*will* do it the standard, eclipse accepted way :-)
> If qualifier-support would drastically decreases performance, you've got
> a good reason not to use them, indeed.
It's possible, but I think the performance aspect would be fine. It's
part of the JSR 330 spec and I don't see anything wrong with using
Qualifier, except we don't have an implementation for it. We were
looking at supporting the ability to add new annotations like
@Preference to be used with @Inject, maybe that's where the
implementation of @Qualifier would be used.
PW
--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .platform.doc.isv/guide/workbench.htm
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
|
|
|
| Re: DI Question [message #525809 is a reply to message #525707] |
Wed, 07 April 2010 20:48 |
Max Bureck
Messages: 72
Registered: July 2009 |
Member |
|
|
> The short answer is we don't currently support that. I don't see
> anything wrong with supporting it (since both annotations are in the
> spec both are there to be used).
And it's not wrong to use @Named. It even makes perfect sense when
combining DI with an expression- or script-language (e.g. in JSF's
unified EL). When using plain Java it's just more readable and less
error-prone to use qualifiers. Since Tom Schindl mentioned that e4
provides complete JSR-330 support, I just assumed that qualifiers are
supported.
>> I'm Sorry, you lost me here. Why are the constants dynamic and how
>> does this affect the question @Named vs. qualifiers?
>
> The keys available for injection are dynamic. Some, like "selection",
> will probably always be there. Some, like "activeContexts", will be
> provided if that service is available (coming from the deployed
> plugins). Others will be provided by the model or the contributing parts
> themselves. @Named is an important part of our story.
Ah, alright. Now I understand. Nevertheless a plug-in could provide it's
own qualifier or use a platform-qualifier instead of using a constant
string. If the strings would be dynamic, like "Row:"+rowNumber,
qualifiers wouldn't make sense.
>> This may seem a bit academic, but if you prefer clean code you should
>> take the advice.
>
> well, if you put it that way then I *don't* prefer clean code and I
> *will* do it the standard, eclipse accepted way :-)
I even found a Wikipedia entry (I didn't create or contributed to ;-) )
on that topic:
http://en.wikipedia.org/wiki/Constant_interface
But if this are Eclipse guidlines, it's the way to go. I do hope those
guidelines get updated though. IMHO it wouldn't be a problem if the
Eclipse Java compiler would understand @noimplement and @noextend.
Regards,
Max
|
|
| | | |
| Re: DI Question [message #573026 is a reply to message #525043] |
Mon, 05 April 2010 15:52 |
Max Bureck
Messages: 72
Registered: July 2009 |
Member |
|
|
Am 05.04.2010 16:25, schrieb Paul Webster:
> Max Bureck wrote:
>> Hello,
>>
>> I was browsing through the EclipseCon e4 slides and found this piece
>> of code:
>>
>> @Inject
>> private void setSelection(@Optional
>> @Named(IServiceConstants.SELECTION) Contact contact) {
>> //…
>> }
>>
>> Why do you use @Named with string constants defined in an interface
>
> @Named is defined in JSR 330 exactly for this purpose.
And @Qualifier is defined in JSR 330 exactly for the purpose to provide
custom Qualifiers. What you do is using a String in @Named, taking away
type-safety and then re-add it by using constants.
It may be more time-consuming to provide a bunch of
qualifier-annotations, but every piece of code that uses the annotations
will be easier to read.
> The constants
> (describing data) that are available from the IEclipseContext are very
> dynamic and many are provided at runtime (SELECTION is data that we know
> will be provided by the framework, but many other pieces of data or
> services are much more dynamic).
I'm Sorry, you lost me here. Why are the constants dynamic and how does
this affect the question @Named vs. qualifiers?
> Using the interface constants is just a way to publish common strings,
> instead of making everybody type out "activeContexts" ... I don't know
> what your dude has against them, but it's a pretty common practice.
> What's his alternative?
The alternatives would be (again suggested by Joshua Bloch, great book BTW)
1. If the constants are tied to specific classes or interfaces, define
them in that classes/interfaces.
2. If 1. is not possible (which seems to be the case for SELECTION)
define the constants in a noninstantiable class (using a private
constructor) instead of in an interface.
The problem with Interfaces is, that the users can implement them. You
may argue that only a moron would do this, but still: It's possible.
This is a problem for the user who implemented it (maybe accidentally),
because it leaks implementation detail and if this is a
public(/exported) class it is part of the API of that class (and
subclasses), so the class has to implement the interface for all time
(or to the next version change breaking backwards compatibility ;-))
This may seem a bit academic, but if you prefer clean code you should
take the advice.
> That's not to say Qualifier can't be supported, but I'm not sure how I
> would impose compile time semantics on information that is decided at
> runtime.
If qualifier-support would drastically decreases performance, you've got
a good reason not to use them, indeed.
Regards,
Max
|
|
|
| Re: DI Question [message #573213 is a reply to message #525058] |
Wed, 07 April 2010 14:13 |
|
Max Bureck wrote:
>
> And @Qualifier is defined in JSR 330 exactly for the purpose to provide
> custom Qualifiers. What you do is using a String in @Named, taking away
> type-safety and then re-add it by using constants.
The short answer is we don't currently support that. I don't see
anything wrong with supporting it (since both annotations are in the
spec both are there to be used).
>> The constants
>> (describing data) that are available from the IEclipseContext are very
>> dynamic and many are provided at runtime (SELECTION is data that we know
>> will be provided by the framework, but many other pieces of data or
>> services are much more dynamic).
>
> I'm Sorry, you lost me here. Why are the constants dynamic and how does
> this affect the question @Named vs. qualifiers?
The keys available for injection are dynamic. Some, like "selection",
will probably always be there. Some, like "activeContexts", will be
provided if that service is available (coming from the deployed
plugins). Others will be provided by the model or the contributing
parts themselves. @Named is an important part of our story.
> The alternatives would be (again suggested by Joshua Bloch, great book BTW)
> 1. If the constants are tied to specific classes or interfaces, define
> them in that classes/interfaces.
Ah, I agree. With one or two exceptions, the constants should be
defined by the service providing them. i.e.
EContextService.ACTIVE_CONTEXTS, ESelectionService.SELECTION, etc. That
some of them are in service constants was a convenience, and their use
from the common interface still has to be reviewed before we ship.
> 2. If 1. is not possible (which seems to be the case for SELECTION)
> define the constants in a noninstantiable class (using a private
> constructor) instead of in an interface.
In eclipse constants are published with an interface, and then the
interface is marked @noimplement, @noextend. A non-instantiable class
would also be acceptable, but the platform standard is the interface.
>
> This may seem a bit academic, but if you prefer clean code you should
> take the advice.
well, if you put it that way then I *don't* prefer clean code and I
*will* do it the standard, eclipse accepted way :-)
> If qualifier-support would drastically decreases performance, you've got
> a good reason not to use them, indeed.
It's possible, but I think the performance aspect would be fine. It's
part of the JSR 330 spec and I don't see anything wrong with using
Qualifier, except we don't have an implementation for it. We were
looking at supporting the ability to add new annotations like
@Preference to be used with @Inject, maybe that's where the
implementation of @Qualifier would be used.
PW
--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .platform.doc.isv/guide/workbench.htm
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
|
|
|
| Re: DI Question [message #573343 is a reply to message #525707] |
Wed, 07 April 2010 20:48 |
Max Bureck
Messages: 72
Registered: July 2009 |
Member |
|
|
> The short answer is we don't currently support that. I don't see
> anything wrong with supporting it (since both annotations are in the
> spec both are there to be used).
And it's not wrong to use @Named. It even makes perfect sense when
combining DI with an expression- or script-language (e.g. in JSF's
unified EL). When using plain Java it's just more readable and less
error-prone to use qualifiers. Since Tom Schindl mentioned that e4
provides complete JSR-330 support, I just assumed that qualifiers are
supported.
>> I'm Sorry, you lost me here. Why are the constants dynamic and how
>> does this affect the question @Named vs. qualifiers?
>
> The keys available for injection are dynamic. Some, like "selection",
> will probably always be there. Some, like "activeContexts", will be
> provided if that service is available (coming from the deployed
> plugins). Others will be provided by the model or the contributing parts
> themselves. @Named is an important part of our story.
Ah, alright. Now I understand. Nevertheless a plug-in could provide it's
own qualifier or use a platform-qualifier instead of using a constant
string. If the strings would be dynamic, like "Row:"+rowNumber,
qualifiers wouldn't make sense.
>> This may seem a bit academic, but if you prefer clean code you should
>> take the advice.
>
> well, if you put it that way then I *don't* prefer clean code and I
> *will* do it the standard, eclipse accepted way :-)
I even found a Wikipedia entry (I didn't create or contributed to ;-) )
on that topic:
http://en.wikipedia.org/wiki/Constant_interface
But if this are Eclipse guidlines, it's the way to go. I do hope those
guidelines get updated though. IMHO it wouldn't be a problem if the
Eclipse Java compiler would understand @noimplement and @noextend.
Regards,
Max
|
|
| | |
Goto Forum:
Current Time: Thu Apr 25 21:15:40 GMT 2024
Powered by FUDForum. Page generated in 0.04125 seconds |
] 
Search
Help
Register
Login
Home
