Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse 4 » DI Question
DI Question [message #524781] Fri, 02 April 2010 13:11 Go to next message
Max Bureck is currently offline Max Bureck
Messages: 72
Registered: July 2009
Member
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
instead of using qualifier annotations? @Selection would be much shorter
than @Named(IServiceConstants.SELECTION). And in addition to that: It's
bad style to use interfaces for the sole purpose to hold constants (see
Joshua Bloch, Effective Java, Item 19: Use interfaces only to define types).

Best regards,
Max
Re: DI Question [message #525043 is a reply to message #524781] Mon, 05 April 2010 14:25 Go to previous messageGo to next message
Paul Webster is currently offline Paul Webster
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

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. 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).

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?

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.

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


Re: DI Question [message #525058 is a reply to message #525043] Mon, 05 April 2010 15:52 Go to previous messageGo to next message
Max Bureck is currently offline 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 Go to previous messageGo to next message
Paul Webster is currently offline Paul Webster
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

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


Re: DI Question [message #525809 is a reply to message #525707] Wed, 07 April 2010 20:48 Go to previous messageGo to next message
Max Bureck is currently offline 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 #526073 is a reply to message #525809] Thu, 08 April 2010 15:43 Go to previous messageGo to next message
Paul Webster is currently offline Paul Webster
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

Max Bureck wrote:
> 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.

Ah, the annotation is included (we provide them with the javax.inject
bundle) but the context injection support wouldn't do anything with them
at the moment, AFAIK.


> 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.

The PDE API builder does, and produces warnings/errors (depending on
your project settings) to help guide people :-)

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


Re: DI Question [message #526227 is a reply to message #526073] Fri, 09 April 2010 09:41 Go to previous message
Max Bureck is currently offline Max Bureck
Messages: 72
Registered: July 2009
Member
>> 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.
>
> The PDE API builder does, and produces warnings/errors (depending on
> your project settings) to help guide people :-)


I knew I should have tested that in more detail :-)

Max
Re: DI Question [message #572921 is a reply to message #524781] Mon, 05 April 2010 14:25 Go to previous message
Paul Webster is currently offline Paul Webster
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

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. 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).

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?

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.

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


Re: DI Question [message #573026 is a reply to message #525043] Mon, 05 April 2010 15:52 Go to previous message
Max Bureck is currently offline 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 Go to previous message
Paul Webster is currently offline Paul Webster
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

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


Re: DI Question [message #573343 is a reply to message #525707] Wed, 07 April 2010 20:48 Go to previous message
Max Bureck is currently offline 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 #573519 is a reply to message #525809] Thu, 08 April 2010 15:43 Go to previous message
Paul Webster is currently offline Paul Webster
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

Max Bureck wrote:
> 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.

Ah, the annotation is included (we provide them with the javax.inject
bundle) but the context injection support wouldn't do anything with them
at the moment, AFAIK.


> 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.

The PDE API builder does, and produces warnings/errors (depending on
your project settings) to help guide people :-)

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


Re: DI Question [message #573626 is a reply to message #526073] Fri, 09 April 2010 09:41 Go to previous message
Max Bureck is currently offline Max Bureck
Messages: 72
Registered: July 2009
Member
>> 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.
>
> The PDE API builder does, and produces warnings/errors (depending on
> your project settings) to help guide people :-)


I knew I should have tested that in more detail :-)

Max
Previous Topic:open Application.e4xmi and the window keeps flashing
Next Topic:open Application.e4xmi and the window keeps flashing
Goto Forum:
  


Current Time: Fri Oct 24 08:39:41 GMT 2014

Powered by FUDForum. Page generated in 0.02264 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software