Bug 316392 - [DI] Auto-convert injected values arrays[1] <-> single objects
Summary: [DI] Auto-convert injected values arrays[1] <-> single objects
Status: ASSIGNED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: E4 (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Oleg Besedin CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-09 17:53 EDT by Thomas Schindl CLA
Modified: 2012-12-13 15:00 EST (History)
5 users (show)

See Also:


Attachments
Experminent with an auto adjusting obejct type (4.50 KB, patch)
2010-06-09 17:55 EDT, Thomas Schindl CLA
no flags Details | Diff
Test showing array injection (3.97 KB, patch)
2010-06-10 11:31 EDT, Oleg Besedin CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Schindl CLA 2010-06-09 17:53:02 EDT
This is most likely something one encounters when e.g. working with the ACTIVE_SELECTION stuff. The problem is that in e4 we typically write methods like this:

----------8<----------
@Inject
public void setSelect(@Named(IServiceConstants.ACTIVE_SELECTION) IResource selection) {
  // ...
}
----------8<----------

which has the problem that if the current-selection is e.g. an Array of IResource[] we don't get something injected.

Possible solutions:
* publish 2 ACTIVE_SELECTION-Values (once as a list and as a single value)
* publish something similar to ISelection in 3.x
* publish something the DI-Stuff understands and evaluates as an array/single 
  value
Comment 1 Thomas Schindl CLA 2010-06-09 17:55:57 EDT
Created attachment 171583 [details]
Experminent with an auto adjusting obejct type

This is a short experiment I made today using a special object know by DI which adjust itself to an Array/Single Value dependending on the injection context
Comment 2 Oleg Besedin CLA 2010-06-10 11:31:07 EDT
Created attachment 171648 [details]
Test showing array injection

We should be able to inject arrays - see the test attached. Same goes for collection objects. 

(As far as I know, array injection has not be used much so I won't be surprised if there are some bugs left in it. Also, injection of byte arrays in @Preferences is not supported for reasons I can't remember right now, but can dig up if anybody is really interested.)

Assuming array injection works, would that do?
Comment 3 Oleg Besedin CLA 2010-06-10 11:35:13 EDT
Thinking about it, I guess the problem with selection is in injecting Object[] when a method says it wants IResource[] ?
Comment 4 Thomas Schindl CLA 2010-06-10 11:45:45 EDT
I know that array injection is working. The problem is that when the value in the context is a singled value it's NOT converted into a Array-Type simply because I want the same as an Array.

e.g. context.set("myKey","Bla") ideally I a method which is defined like this

@Inject
public void setMyKeys(@Named("myKey") String[] s) {
}

would get injected an array with length=1
Comment 5 Oleg Besedin CLA 2010-06-10 13:38:31 EDT
(In reply to comment #4)
> I know that array injection is working. The problem is that when the value in
> the context is a singled value it's NOT converted into a Array-Type simply
> because I want the same as an Array.

I see now. Yes, it would be convenient to have autoconversion Object[1] { ObjectABC } <-> Object ObjectABC

Some potentual issues:

(a) if we autoconvert from { ObjectABC } to ObjectABC, we won't be able to track changes to the ObjectABC and propagate them into injected values (and client code will have no way to know about it);
(b) memory and performance overhead;
(c) how generic is this case?
(c) next, we'll be asked to convert primitive types to arrays, multi-dimensional arrays, lists to arrays, and what not :-)

I would be inclined to leave this open and return to this request in mid- or late 4.1 cycle once we have better grasp on what are the common use patterns.
Comment 6 Thomas Schindl CLA 2010-06-10 14:30:56 EDT
(In reply to comment #5)
> (In reply to comment #4)
> > I know that array injection is working. The problem is that when the value in
> > the context is a singled value it's NOT converted into a Array-Type simply
> > because I want the same as an Array.
> 
> I see now. Yes, it would be convenient to have autoconversion Object[1] {
> ObjectABC } <-> Object ObjectABC
> 
> Some potentual issues:
> 
> (a) if we autoconvert from { ObjectABC } to ObjectABC, we won't be able to
> track changes to the ObjectABC and propagate them into injected values (and
> client code will have no way to know about it);

Doesn't my example code with an Chimera-type solves this? The value changed is always the wrapped type

> (b) memory and performance overhead;
> (c) how generic is this case?
> (c) next, we'll be asked to convert primitive types to arrays,
> multi-dimensional arrays, lists to arrays, and what not :-)
> 
> I would be inclined to leave this open and return to this request in mid- or
> late 4.1 cycle once we have better grasp on what are the common use patterns.

Though I would have hoped we find a solution in 4.0 I understand that we'll have to solve more pressing issues.
Comment 7 Paul Webster CLA 2010-06-21 15:03:42 EDT
Just a note.  The default variable in 3.x is a Collection representing the selection.  An ITextSelection gets a Collection of its own.  An IStructuredSelection is simply turned into a List.

But the "selection" variable is always simply the ISelection.

PW