[jira] Issue Comment Edited: (COCOON3-14) Use generics for pipeline assembly
[
https://issues.apache.org/jira/browse/COCOON3-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666936#action_12666936
]
grek edited comment on COCOON3-14 at 1/24/09 6:41 AM:
--
The supplied patch does not change how the components interact with each
other.
The PipelineComponent interface remains unchanged.
I didn't formulate my question clearly: what is our intention. Do we want a
generic API for event exchange or each pair of components will be dealing with
this in it's implementation by doing some of instanceof checks?
This is always the case when the Pipeline is assembled at runtime from a
provided description, like the Sitemap.
While the PipelineAPI is intended do be used with direct calls from the
user's code, we should not forget that automatic pipeline
construction using some kind of description is still a valid use case and
that basically no assumptions about
the actual components can be made in such a case (iow Generics are pretty
much worthless for that)
It's not entirely true that generics are worhtless at runtime. Take a look at
quick prototype:
{code:title=PipelineComponent.java|borderStyle=solid}
package test;
public interface PipelineComponentT, U {
U execute(T event);
}
{code}
TestComponent.java
package test;
import java.util.LinkedList;
import java.util.List;
public class TestCompoent implements PipelineComponentString, ListString {
public ListString execute(String event) {
ListString list = new LinkedListString();
list.add(event);
return list;
}
}
main.java
package test;
import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Type;
public class main {
public static void main(String[] args) {
Type[] interfaces = TestCompoent.class.getGenericInterfaces();
for (Type i : interfaces) {
if (i instanceof ParameterizedType) {
ParameterizedType pt = (ParameterizedType)i;
if
(pt.getRawType().equals(PipelineComponent.class)) {
Type[] typeArguments =
pt.getActualTypeArguments();
Type input = typeArguments[0];
Type output = typeArguments[1];
System.out.println(TestCompoent.class +
is +
PipelineComponent + input + , +
output + );
}
}
}
}
}
This gives me following output:
class test.TestCompoent is PipelineComponentclass java.lang.String,
java.util.Listjava.lang.String
My point is that Pipeline *can* and *should* check if it's valid (given
components can be combined). Of course this will work only if one component
accepts one type of input and produces one type of output but I don't see this
as a problem.
was (Author: grek):
The supplied patch does not change how the components interact with each
other.
The PipelineComponent interface remains unchanged.
I didn't formulate my question clearly: what is our intention. Do we want a
generic API for event exchange or each pair of components will be dealing with
this in it's implementation by doing some of instanceof checks?
This is always the case when the Pipeline is assembled at runtime from a
provided description, like the Sitemap.
While the PipelineAPI is intended do be used with direct calls from the
user's code, we should not forget that automatic pipeline
construction using some kind of description is still a valid use case and
that basically no assumptions about
the actual components can be made in such a case (iow Generics are pretty
much worthless for that)
It's not entirely true that generics are worhtless at runtime. Take a look at
quick prototype:
{code}
PipelineComponent.java
package test;
public interface PipelineComponentT, U {
U execute(T event);
}
{code}
TestComponent.java
package test;
import java.util.LinkedList;
import java.util.List;
public class TestCompoent implements PipelineComponentString, ListString {
public ListString execute(String event) {
ListString list = new LinkedListString();
list.add(event);
return list;
}
}
main.java
[jira] Issue Comment Edited: (COCOON3-14) Use generics for pipeline assembly
[
https://issues.apache.org/jira/browse/COCOON3-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666936#action_12666936
]
grek edited comment on COCOON3-14 at 1/24/09 6:40 AM:
--
The supplied patch does not change how the components interact with each
other.
The PipelineComponent interface remains unchanged.
I didn't formulate my question clearly: what is our intention. Do we want a
generic API for event exchange or each pair of components will be dealing with
this in it's implementation by doing some of instanceof checks?
This is always the case when the Pipeline is assembled at runtime from a
provided description, like the Sitemap.
While the PipelineAPI is intended do be used with direct calls from the
user's code, we should not forget that automatic pipeline
construction using some kind of description is still a valid use case and
that basically no assumptions about
the actual components can be made in such a case (iow Generics are pretty
much worthless for that)
It's not entirely true that generics are worhtless at runtime. Take a look at
quick prototype:
{code}
PipelineComponent.java
package test;
public interface PipelineComponentT, U {
U execute(T event);
}
{code}
TestComponent.java
package test;
import java.util.LinkedList;
import java.util.List;
public class TestCompoent implements PipelineComponentString, ListString {
public ListString execute(String event) {
ListString list = new LinkedListString();
list.add(event);
return list;
}
}
main.java
package test;
import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Type;
public class main {
public static void main(String[] args) {
Type[] interfaces = TestCompoent.class.getGenericInterfaces();
for (Type i : interfaces) {
if (i instanceof ParameterizedType) {
ParameterizedType pt = (ParameterizedType)i;
if
(pt.getRawType().equals(PipelineComponent.class)) {
Type[] typeArguments =
pt.getActualTypeArguments();
Type input = typeArguments[0];
Type output = typeArguments[1];
System.out.println(TestCompoent.class +
is +
PipelineComponent + input + , +
output + );
}
}
}
}
}
This gives me following output:
class test.TestCompoent is PipelineComponentclass java.lang.String,
java.util.Listjava.lang.String
My point is that Pipeline *can* and *should* check if it's valid (given
components can be combined). Of course this will work only if one component
accepts one type of input and produces one type of output but I don't see this
as a problem.
was (Author: grek):
The supplied patch does not change how the components interact with each
other.
The PipelineComponent interface remains unchanged.
I didn't formulate my question clearly: what is our intention. Do we want a
generic API for event exchange or each pair of components will be dealing with
this in it's implementation by doing some of instanceof checks?
This is always the case when the Pipeline is assembled at runtime from a
provided description, like the Sitemap.
While the PipelineAPI is intended do be used with direct calls from the
user's code, we should not forget that automatic pipeline
construction using some kind of description is still a valid use case and
that basically no assumptions about
the actual components can be made in such a case (iow Generics are pretty
much worthless for that)
It's not entirely true that generics are worhtless at runtime. Take a look at
quick prototype:
PipelineComponent.java
package test;
public interface PipelineComponentT, U {
U execute(T event);
}
TestComponent.java
package test;
import java.util.LinkedList;
import java.util.List;
public class TestCompoent implements PipelineComponentString, ListString {
public ListString execute(String event) {
ListString list = new LinkedListString();
list.add(event);
return list;
}
}
main.java
[jira] Issue Comment Edited: (COCOON3-14) Use generics for pipeline assembly
[
https://issues.apache.org/jira/browse/COCOON3-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666936#action_12666936
]
grek edited comment on COCOON3-14 at 1/24/09 6:42 AM:
--
The supplied patch does not change how the components interact with each
other.
The PipelineComponent interface remains unchanged.
I didn't formulate my question clearly: what is our intention. Do we want a
generic API for event exchange or each pair of components will be dealing with
this in it's implementation by doing some of instanceof checks?
This is always the case when the Pipeline is assembled at runtime from a
provided description, like the Sitemap.
While the PipelineAPI is intended do be used with direct calls from the
user's code, we should not forget that automatic pipeline
construction using some kind of description is still a valid use case and
that basically no assumptions about
the actual components can be made in such a case (iow Generics are pretty
much worthless for that)
It's not entirely true that generics are worhtless at runtime. Take a look at
quick prototype:
PipelineComponent.java
package test;
public interface PipelineComponentT, U {
U execute(T event);
}
TestComponent.java
package test;
import java.util.LinkedList;
import java.util.List;
public class TestCompoent implements PipelineComponentString, ListString {
public ListString execute(String event) {
ListString list = new LinkedListString();
list.add(event);
return list;
}
}
main.java
package test;
import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Type;
public class main {
public static void main(String[] args) {
Type[] interfaces = TestCompoent.class.getGenericInterfaces();
for (Type i : interfaces) {
if (i instanceof ParameterizedType) {
ParameterizedType pt = (ParameterizedType)i;
if
(pt.getRawType().equals(PipelineComponent.class)) {
Type[] typeArguments =
pt.getActualTypeArguments();
Type input = typeArguments[0];
Type output = typeArguments[1];
System.out.println(TestCompoent.class +
is +
PipelineComponent + input + , +
output + );
}
}
}
}
}
This gives me following output:
class test.TestCompoent is PipelineComponentclass java.lang.String,
java.util.Listjava.lang.String
My point is that Pipeline *can* and *should* check if it's valid (given
components can be combined). Of course this will work only if one component
accepts one type of input and produces one type of output but I don't see this
as a problem.
was (Author: grek):
The supplied patch does not change how the components interact with each
other.
The PipelineComponent interface remains unchanged.
I didn't formulate my question clearly: what is our intention. Do we want a
generic API for event exchange or each pair of components will be dealing with
this in it's implementation by doing some of instanceof checks?
This is always the case when the Pipeline is assembled at runtime from a
provided description, like the Sitemap.
While the PipelineAPI is intended do be used with direct calls from the
user's code, we should not forget that automatic pipeline
construction using some kind of description is still a valid use case and
that basically no assumptions about
the actual components can be made in such a case (iow Generics are pretty
much worthless for that)
It's not entirely true that generics are worhtless at runtime. Take a look at
quick prototype:
{code:title=PipelineComponent.java|borderStyle=solid}
package test;
public interface PipelineComponentT, U {
U execute(T event);
}
{code}
TestComponent.java
package test;
import java.util.LinkedList;
import java.util.List;
public class TestCompoent implements PipelineComponentString, ListString {
public ListString execute(String event) {
ListString list = new LinkedListString();
list.add(event);
return list;
}
}
main.java
package test;
[jira] Issue Comment Edited: (COCOON3-14) Use generics for pipeline assembly
[ https://issues.apache.org/jira/browse/COCOON3-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666541#action_12666541 ] cziegeler edited comment on COCOON3-14 at 1/23/09 5:46 AM: -- Hmm I still don't think so :) As far as I understood all the discussions it is now allowed to mix sax with stax or dom components in a pipeline, they are required to use the eventing (if you regard dom as one single big event). was (Author: cziegeler): Hmm I still don't so :) As far as I understood all the discussions it is now allowed to mix sax with stax or dom components in a pipeline, they are required to use the eventing (if you regard dom as one single big event). Use generics for pipeline assembly -- Key: COCOON3-14 URL: https://issues.apache.org/jira/browse/COCOON3-14 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-pipeline Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Attachments: generics.patch This is a simple patch to add generics to the pipeline interface and impl. With additionally introducing marker interfaces for the component types (SAX, Stax, dom) this would allow compile time checks if all components have the correct type when assembling the pipeline. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
