[jira] [Updated] (FELIX-5996) Remove generic parameter in DM Component interface

["Pierre De Rop (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/FELIX-5996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pierre De Rop updated FELIX-5996:
---------------------------------
    Description: 
Since dm-r13, the Component interface is now taking a generic parameter so it make it easier to define extended components like adapters.

So, with this new model, it looks like the following:
{code:java}
public interface Component<T extends Component<T>> {
   T setInterface(String service, Dictionary properties)
   T setImplementation(Object ob);
   ...
}
public interface AdapterComponent extends Component<AdapterComponent> {
   AdapterComponent setAdaptee(Class<?> service, String filter);
   AdapterComponent setAdapteeCallbacks(String add, String change, String remove, String swap);
   ...
}
{code}
and you can now do something like this:
{code:java}
Component adapter = createAdapterComponent()
  .setAdaptee(Adaptee.class, "(foo=bar)")
  .setAdapteeCallbacks("setAdaptee", "changeAdaptee", null, null)
  .setImplementation(AdapterImpl.class)
  .setInterface(AdapterService.class, null)
  .add(createServiceDependency().setService(LogService.class));
{code}
now, while using the generic parameter simplify the declaration of component adapters, it has a drawback: the Component now takes a generic parameter, and old code using simple components now generates a compilation warning:
{code:java}
Component adapter = createComponent()
 .setImplementation(SimpleComponent.class)
 ...
{code}
so, the above example generates a compilation warning, and you now have to declare "?" in order to get rid of the warning:
{code:java}
Component<?> adapter = createComponent()
 .setImplementation(SimpleComponent.class)
 ...
{code}
that being said, maybe we can refactor in order to get rid of the generic parameter, by copying the top level component methods in sub interfaces, like this:
{code:java}
public interface Component {
 Component setInterface(String service, Dictionary properties);
 Component setImplementation(Object ob);
 ...
 }

public interface AdapterComponent extends Component
{
 // Component methods with specialized signatures 
AdapterComponent setInterface(String service, Dictionary properties) 
AdapterComponent setImplementation(Object ob);

// AdapterComponent methods
AdapterComponent methods AdapterComponent setAdaptee(Class<?> service, String filter); 
AdapterComponent setAdapteeCallbacks(String add, String change, String remove, String swap); 
 }
{code}

  was:
Since dm-r13, the Component interface is now taking a generic parameter so it make it easier to define extended components like adapters.

So, with this new model, it looks like the following:
{code:java}
public interface Component<T extends Component<T>> {
   T setInterface(String service, Dictionary properties)
   T setImplementation(Object ob);
   ...
}
public interface AdapterComponent extends Component<AdapterComponent> {
   AdapterComponent setAdaptee(Class<?> service, String filter);
   AdapterComponent setAdapteeCallbacks(String add, String change, String remove, String swap);
   ...
}
{code}
and you can now do something like this:
{code:java}
Component adapter = createAdapterComponent()
  .setAdaptee(Adaptee.class, "(foo=bar)")
  .setAdapteeCallbacks("setAdaptee", "changeAdaptee", null, null)
  .setImplementation(AdapterImpl.class)
  .setInterface(AdapterService.class, null)
  .add(createServiceDependency().setService(LogService.class));
{code}
now, while using the generic parameter simplify the declaration of component adapters, it has a drawback: the Component now takes a generic parameter, and old code using simple components now generates a compilation warning:
{code:java}
Component adapter = createComponent()
 .setImplementation(SimpleComponent.class)
 ...
{code}
so, the above example generates a compilation warning, and you now have to declare "?" in order to get rid of the warning:
{code:java}
Component<?> adapter = createComponent()
 .setImplementation(SimpleComponent.class)
 ...
{code}
that being said, maybe we can refactor in order to get rid of the generic parameter, by copying the top level component methods in sub interfaces, like this:
{code:java}
public interface Component {
 Component setInterface(String service, Dictionary properties);
 Component setImplementation(Object ob);
 ...
 }

public interface AdapterComponent extends Component

{ // Component methods with specialized signatures AdapterComponent setInterface(String service, Dictionary properties) AdapterComponent setImplementation(Object ob); … // AdapterComponent methods AdapterComponent setAdaptee(Class<?> service, String filter); AdapterComponent setAdapteeCallbacks(String add, String change, String remove, String swap); 

{code}


> Remove generic parameter in DM Component interface
> --------------------------------------------------
>
>                 Key: FELIX-5996
>                 URL: https://issues.apache.org/jira/browse/FELIX-5996
>             Project: Felix
>          Issue Type: Task
>          Components: Dependency Manager
>    Affects Versions: org.apache.felix.dependencymanager-r13
>            Reporter: Pierre De Rop
>            Assignee: Pierre De Rop
>            Priority: Minor
>
> Since dm-r13, the Component interface is now taking a generic parameter so it make it easier to define extended components like adapters.
> So, with this new model, it looks like the following:
> {code:java}
> public interface Component<T extends Component<T>> {
>    T setInterface(String service, Dictionary properties)
>    T setImplementation(Object ob);
>    ...
> }
> public interface AdapterComponent extends Component<AdapterComponent> {
>    AdapterComponent setAdaptee(Class<?> service, String filter);
>    AdapterComponent setAdapteeCallbacks(String add, String change, String remove, String swap);
>    ...
> }
> {code}
> and you can now do something like this:
> {code:java}
> Component adapter = createAdapterComponent()
>   .setAdaptee(Adaptee.class, "(foo=bar)")
>   .setAdapteeCallbacks("setAdaptee", "changeAdaptee", null, null)
>   .setImplementation(AdapterImpl.class)
>   .setInterface(AdapterService.class, null)
>   .add(createServiceDependency().setService(LogService.class));
> {code}
> now, while using the generic parameter simplify the declaration of component adapters, it has a drawback: the Component now takes a generic parameter, and old code using simple components now generates a compilation warning:
> {code:java}
> Component adapter = createComponent()
>  .setImplementation(SimpleComponent.class)
>  ...
> {code}
> so, the above example generates a compilation warning, and you now have to declare "?" in order to get rid of the warning:
> {code:java}
> Component<?> adapter = createComponent()
>  .setImplementation(SimpleComponent.class)
>  ...
> {code}
> that being said, maybe we can refactor in order to get rid of the generic parameter, by copying the top level component methods in sub interfaces, like this:
> {code:java}
> public interface Component {
>  Component setInterface(String service, Dictionary properties);
>  Component setImplementation(Object ob);
>  ...
>  }
> public interface AdapterComponent extends Component
> {
>  // Component methods with specialized signatures 
> AdapterComponent setInterface(String service, Dictionary properties) 
> AdapterComponent setImplementation(Object ob);
> // AdapterComponent methods
> AdapterComponent methods AdapterComponent setAdaptee(Class<?> service, String filter); 
> AdapterComponent setAdapteeCallbacks(String add, String change, String remove, String swap); 
>  }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)