You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Chris Howe <cj...@yahoo.com> on 2007/05/19 21:20:43 UTC

Simple Methods, subtyping, substitution principle

Q: Do the call-*-method implement subtyping of arguments correctly (or
at all)?

Background:
I still only know enough java programming to be dangerous and have been
reading what I can get my hands on when the opportunity arises and
comparing it to some of my experiences with OFBiz.  Since the
community's official move to Java 5, I've been reading a bit about
generics and subtyping.  Wherever a value of one type is expected one
may provide a value of any subtype of that type.

In my working with getting OFBiz to talk to an Asterisk server, I found
this not to hold with simple methods <call-*-method>.  I wanted to
ensure my expectations and observations were correct before creating a
Jira issue and investing time in it.

So, my three questions I'd like to have verified follow:

1) Does <call-*-method> with subelement <field name="xyz"
type="subtypeOfMethodsExpectedClass"/> work?
2) Should <call-*-method> with subelement <field name="xyz"
type="subtypeOfMethodsExpectedClass"/> work?
3) If 1 is yes and 2 is no, is it possible for it to work?

I'd be happy to invest the time in making this work if I can get some
confirmation that there isn't a reason not to.
Thanks!


Re: Simple Methods, subtyping, substitution principle

Posted by Chris Howe <cj...@yahoo.com>.
Let me see if I understand the risk case correctly.
Given:

class foo
class bar
class baz extends foo
class bop extends bar

someMethod(foo arg1, bar arg2)
someMethod(baz arg1, bop arg2) -- Not implemented
someMethod(foo arg1, bop arg2)
someMethod(baz arg1, bar arg2)

<call-class-method class="org.ofbiz.util.someClass"
method="someMethod">
 <field name="bazArg"/>
 <field name="bopArg"/>
</call-class-method>

If the 2nd method DNE It would be unreliable on whether the 3rd or 4th
method would/should be run?  

Is it true that Java itself doesn't have this risk because the compiler
will complain when it's ambiguous?

As unit tests become more pervasive in Ofbiz, could a unit test create
a pseudo compiler to mitigate this risk?

--- David E Jones <jo...@hotwaxmedia.com> wrote:

> 
> Hmmmm... I see more of what you mean now.
> 
> It should be possible to implement that, but would require a little
> bit of work AND it would introduce the risk of what we run into with
> BSH scripts and FTL template where on occasion which is that there
> are multiple methods in a class with the given name and that match
> the method signature.
> 
> In the initial simple-method implementation I decided to avoid this
> and just require that you specify the type according to what is in
> the definition of the method being called.
> 
> In other words, the type of the field is really NOT meant to be the
> type of object being passed in for cases of inheritance and such, but
> rather the type in the method signature.
> 
> I'm guessing this discussion and the confusion is mostly about the
> intent of that attribute. In SVN rev 539811 I added some comments to
> the annotation in the XSD file that will hopefully help to clarify
> this.
> 
> -David
> 
> 
> Chris Howe wrote:
> > I think most of the community code decides to implement things
> through
> > java or <call-bsh> when they come up against this issue, I doubt
> there
> > exists anything in the codebase that could demonstrate this easily,
> I
> > will hunt though.
> > 
> > If you're interested in looking I did circumvent this in the
> Xindice
> > POC
> > https://issues.apache.org/jira/browse/OFBIZ-851
> > in
> /script/org/ofbiz/xindice/XindiceServices.xml#ofbizXindiceConfigInit
> > 
> > <create-object
> > class-name="org.apache.xindice.client.xmldb.DatabaseImpl"
> > field-name="database"/>
> > <call-class-method method-name="registerDatabase"
> > class-name="org.xmldb.api.DatabaseManager">
> >  <field field-name="database" type="org.xmldb.api.base.Database"/>
> > </call-class-method>
> > 
> > if subtyping worked, I should be able to pass in 
> >  <field field-name="database"
> > type="org.apache.xindice.client.xmldb.DatabaseImpl"/>
> > 
> > or... not even need to specify a type
> > 
> > as org.apache.xindice.client.xmldb.DatabaseImpl implements
> > org.xmldb.api.base.Database
> >
>
http://xml.apache.org/xindice/api/org/apache/xindice/client/xmldb/DatabaseImpl.html
> > 
> > This assumption is why I asked question #2.  
> > 
> > --- David E Jones <jo...@hotwaxmedia.com> wrote:
> > 
> >> Yes, it should support sub-types and match them to interfaces
> >> implemented or classes extended in method signatures. We have some
> >> stuff that does this in other areas, like in the ObjectType stuff
> for
> >> checking types. When calling a method dynamically like this the
> Java
> >> API should take care of this, so I'm not sure why it is not...
> >>
> >> So yeah, an issue and a simple test case that can show it broken
> and
> >> confirm it fixed (like an example simple method snippet or
> something)
> >> would be great.
> >>
> >> -David
> >>
> >>
> >> Chris Howe wrote:
> >>> Q: Do the call-*-method implement subtyping of arguments
> correctly
> >> (or
> >>> at all)?
> >>>
> >>> Background:
> >>> I still only know enough java programming to be dangerous and
> have
> >> been
> >>> reading what I can get my hands on when the opportunity arises
> and
> >>> comparing it to some of my experiences with OFBiz.  Since the
> >>> community's official move to Java 5, I've been reading a bit
> about
> >>> generics and subtyping.  Wherever a value of one type is expected
> >> one
> >>> may provide a value of any subtype of that type.
> >>>
> >>> In my working with getting OFBiz to talk to an Asterisk server, I
> >> found
> >>> this not to hold with simple methods <call-*-method>.  I wanted
> to
> >>> ensure my expectations and observations were correct before
> >> creating a
> >>> Jira issue and investing time in it.
> >>>
> >>> So, my three questions I'd like to have verified follow:
> >>>
> >>> 1) Does <call-*-method> with subelement <field name="xyz"
> >>> type="subtypeOfMethodsExpectedClass"/> work?
> >>> 2) Should <call-*-method> with subelement <field name="xyz"
> >>> type="subtypeOfMethodsExpectedClass"/> work?
> >>> 3) If 1 is yes and 2 is no, is it possible for it to work?
> >>>
> >>> I'd be happy to invest the time in making this work if I can get
> >> some
> >>> confirmation that there isn't a reason not to.
> >>> Thanks!
> >>>
> > 
> 


Re: Simple Methods, subtyping, substitution principle

Posted by David E Jones <jo...@hotwaxmedia.com>.
Hmmmm... I see more of what you mean now.

It should be possible to implement that, but would require a little bit of work AND it would introduce the risk of what we run into with BSH scripts and FTL template where on occasion which is that there are multiple methods in a class with the given name and that match the method signature.

In the initial simple-method implementation I decided to avoid this and just require that you specify the type according to what is in the definition of the method being called.

In other words, the type of the field is really NOT meant to be the type of object being passed in for cases of inheritance and such, but rather the type in the method signature.

I'm guessing this discussion and the confusion is mostly about the intent of that attribute. In SVN rev 539811 I added some comments to the annotation in the XSD file that will hopefully help to clarify this.

-David


Chris Howe wrote:
> I think most of the community code decides to implement things through
> java or <call-bsh> when they come up against this issue, I doubt there
> exists anything in the codebase that could demonstrate this easily, I
> will hunt though.
> 
> If you're interested in looking I did circumvent this in the Xindice
> POC
> https://issues.apache.org/jira/browse/OFBIZ-851
> in /script/org/ofbiz/xindice/XindiceServices.xml#ofbizXindiceConfigInit
> 
> <create-object
> class-name="org.apache.xindice.client.xmldb.DatabaseImpl"
> field-name="database"/>
> <call-class-method method-name="registerDatabase"
> class-name="org.xmldb.api.DatabaseManager">
>  <field field-name="database" type="org.xmldb.api.base.Database"/>
> </call-class-method>
> 
> if subtyping worked, I should be able to pass in 
>  <field field-name="database"
> type="org.apache.xindice.client.xmldb.DatabaseImpl"/>
> 
> or... not even need to specify a type
> 
> as org.apache.xindice.client.xmldb.DatabaseImpl implements
> org.xmldb.api.base.Database
> http://xml.apache.org/xindice/api/org/apache/xindice/client/xmldb/DatabaseImpl.html
> 
> This assumption is why I asked question #2.  
> 
> --- David E Jones <jo...@hotwaxmedia.com> wrote:
> 
>> Yes, it should support sub-types and match them to interfaces
>> implemented or classes extended in method signatures. We have some
>> stuff that does this in other areas, like in the ObjectType stuff for
>> checking types. When calling a method dynamically like this the Java
>> API should take care of this, so I'm not sure why it is not...
>>
>> So yeah, an issue and a simple test case that can show it broken and
>> confirm it fixed (like an example simple method snippet or something)
>> would be great.
>>
>> -David
>>
>>
>> Chris Howe wrote:
>>> Q: Do the call-*-method implement subtyping of arguments correctly
>> (or
>>> at all)?
>>>
>>> Background:
>>> I still only know enough java programming to be dangerous and have
>> been
>>> reading what I can get my hands on when the opportunity arises and
>>> comparing it to some of my experiences with OFBiz.  Since the
>>> community's official move to Java 5, I've been reading a bit about
>>> generics and subtyping.  Wherever a value of one type is expected
>> one
>>> may provide a value of any subtype of that type.
>>>
>>> In my working with getting OFBiz to talk to an Asterisk server, I
>> found
>>> this not to hold with simple methods <call-*-method>.  I wanted to
>>> ensure my expectations and observations were correct before
>> creating a
>>> Jira issue and investing time in it.
>>>
>>> So, my three questions I'd like to have verified follow:
>>>
>>> 1) Does <call-*-method> with subelement <field name="xyz"
>>> type="subtypeOfMethodsExpectedClass"/> work?
>>> 2) Should <call-*-method> with subelement <field name="xyz"
>>> type="subtypeOfMethodsExpectedClass"/> work?
>>> 3) If 1 is yes and 2 is no, is it possible for it to work?
>>>
>>> I'd be happy to invest the time in making this work if I can get
>> some
>>> confirmation that there isn't a reason not to.
>>> Thanks!
>>>
> 

Re: Simple Methods, subtyping, substitution principle

Posted by Chris Howe <cj...@yahoo.com>.
I think most of the community code decides to implement things through
java or <call-bsh> when they come up against this issue, I doubt there
exists anything in the codebase that could demonstrate this easily, I
will hunt though.

If you're interested in looking I did circumvent this in the Xindice
POC
https://issues.apache.org/jira/browse/OFBIZ-851
in /script/org/ofbiz/xindice/XindiceServices.xml#ofbizXindiceConfigInit

<create-object
class-name="org.apache.xindice.client.xmldb.DatabaseImpl"
field-name="database"/>
<call-class-method method-name="registerDatabase"
class-name="org.xmldb.api.DatabaseManager">
 <field field-name="database" type="org.xmldb.api.base.Database"/>
</call-class-method>

if subtyping worked, I should be able to pass in 
 <field field-name="database"
type="org.apache.xindice.client.xmldb.DatabaseImpl"/>

or... not even need to specify a type

as org.apache.xindice.client.xmldb.DatabaseImpl implements
org.xmldb.api.base.Database
http://xml.apache.org/xindice/api/org/apache/xindice/client/xmldb/DatabaseImpl.html

This assumption is why I asked question #2.  

--- David E Jones <jo...@hotwaxmedia.com> wrote:

> 
> Yes, it should support sub-types and match them to interfaces
> implemented or classes extended in method signatures. We have some
> stuff that does this in other areas, like in the ObjectType stuff for
> checking types. When calling a method dynamically like this the Java
> API should take care of this, so I'm not sure why it is not...
> 
> So yeah, an issue and a simple test case that can show it broken and
> confirm it fixed (like an example simple method snippet or something)
> would be great.
> 
> -David
> 
> 
> Chris Howe wrote:
> > Q: Do the call-*-method implement subtyping of arguments correctly
> (or
> > at all)?
> > 
> > Background:
> > I still only know enough java programming to be dangerous and have
> been
> > reading what I can get my hands on when the opportunity arises and
> > comparing it to some of my experiences with OFBiz.  Since the
> > community's official move to Java 5, I've been reading a bit about
> > generics and subtyping.  Wherever a value of one type is expected
> one
> > may provide a value of any subtype of that type.
> > 
> > In my working with getting OFBiz to talk to an Asterisk server, I
> found
> > this not to hold with simple methods <call-*-method>.  I wanted to
> > ensure my expectations and observations were correct before
> creating a
> > Jira issue and investing time in it.
> > 
> > So, my three questions I'd like to have verified follow:
> > 
> > 1) Does <call-*-method> with subelement <field name="xyz"
> > type="subtypeOfMethodsExpectedClass"/> work?
> > 2) Should <call-*-method> with subelement <field name="xyz"
> > type="subtypeOfMethodsExpectedClass"/> work?
> > 3) If 1 is yes and 2 is no, is it possible for it to work?
> > 
> > I'd be happy to invest the time in making this work if I can get
> some
> > confirmation that there isn't a reason not to.
> > Thanks!
> > 
> 


Re: Simple Methods, subtyping, substitution principle

Posted by David E Jones <jo...@hotwaxmedia.com>.
Yes, it should support sub-types and match them to interfaces implemented or classes extended in method signatures. We have some stuff that does this in other areas, like in the ObjectType stuff for checking types. When calling a method dynamically like this the Java API should take care of this, so I'm not sure why it is not...

So yeah, an issue and a simple test case that can show it broken and confirm it fixed (like an example simple method snippet or something) would be great.

-David


Chris Howe wrote:
> Q: Do the call-*-method implement subtyping of arguments correctly (or
> at all)?
> 
> Background:
> I still only know enough java programming to be dangerous and have been
> reading what I can get my hands on when the opportunity arises and
> comparing it to some of my experiences with OFBiz.  Since the
> community's official move to Java 5, I've been reading a bit about
> generics and subtyping.  Wherever a value of one type is expected one
> may provide a value of any subtype of that type.
> 
> In my working with getting OFBiz to talk to an Asterisk server, I found
> this not to hold with simple methods <call-*-method>.  I wanted to
> ensure my expectations and observations were correct before creating a
> Jira issue and investing time in it.
> 
> So, my three questions I'd like to have verified follow:
> 
> 1) Does <call-*-method> with subelement <field name="xyz"
> type="subtypeOfMethodsExpectedClass"/> work?
> 2) Should <call-*-method> with subelement <field name="xyz"
> type="subtypeOfMethodsExpectedClass"/> work?
> 3) If 1 is yes and 2 is no, is it possible for it to work?
> 
> I'd be happy to invest the time in making this work if I can get some
> confirmation that there isn't a reason not to.
> Thanks!
> 

Re: Simple Methods, subtyping, substitution principle

Posted by Chris Howe <cj...@yahoo.com>.
Woops, I inverted question 3...should be if 1 is no and 2 is yes
--- Chris Howe <cj...@yahoo.com> wrote:

> Q: Do the call-*-method implement subtyping of arguments correctly
> (or
> at all)?
> 
> Background:
> I still only know enough java programming to be dangerous and have
> been
> reading what I can get my hands on when the opportunity arises and
> comparing it to some of my experiences with OFBiz.  Since the
> community's official move to Java 5, I've been reading a bit about
> generics and subtyping.  Wherever a value of one type is expected one
> may provide a value of any subtype of that type.
> 
> In my working with getting OFBiz to talk to an Asterisk server, I
> found
> this not to hold with simple methods <call-*-method>.  I wanted to
> ensure my expectations and observations were correct before creating
> a
> Jira issue and investing time in it.
> 
> So, my three questions I'd like to have verified follow:
> 
> 1) Does <call-*-method> with subelement <field name="xyz"
> type="subtypeOfMethodsExpectedClass"/> work?
> 2) Should <call-*-method> with subelement <field name="xyz"
> type="subtypeOfMethodsExpectedClass"/> work?
> 3) If 1 is yes and 2 is no, is it possible for it to work?
> 
> I'd be happy to invest the time in making this work if I can get some
> confirmation that there isn't a reason not to.
> Thanks!
> 
>