java.lang.NumberFormatException from java.io.Writer.write()

[Mike Cowlishaw]

 

Mike - thanks for suggesting a very informative test case which may help people see what is happening! 
 

And thanks for a nice exposition and demo!

 
Although it seems a little unnatural to create a NetRexx method that accepts a Java type object (for local access - I do it a lot for external callbacks from Java code), one could hypothesize a case where the method is called both from Java code and NetRexx code. 

 

(e.g., the superclass is an existing Java class -- as in the original reported problem)

 

So here is my hypothetical code with a String method in a superclass that matches an "int" method in a subclass along with the results it achieved:

----------------------- code: ------------------------------------- 

<snip> 
----------------------------------------------------------------------------- 
This test sequence does not provide much new information but it may clarify the effect of the changes for some people. I think it also shows that the changed "after3.01" compiler is much more likely to compile and run programs as most programmers would expect.

Nicely demonstrated -- yes that shows the issues.  Your last sentence is actually a reminder that (as I was breaking new ground) I may have been erring on the cautious side and preferring errors to be raised in 'grey areas'.   I think your proposed change is an improvement.  Now you guys just to figure out if it might break too mauch :-).  

 
BTW, I have two copies of the book "The NetRexx Language" next to my computer and probably have a copy of the Rexx book buried somewhere nearby also.   OK.  Look forward to hearing what you think about my documentation thoughts.

Also I have not touched any documentation because I think René was correct to require an SVN lock on the manuals to reduce conflicts in updates since we cannot easily identify changes at this time. So I have been waiting to update the documents until 3.01 is final release to prevent difficult doc merges from alternate branches.  

 

Updating the doc is the job of the Project Editor -- that avoids all the merge hassles, etc.  All you have to do is present the suggested change to the existing doc, e.g., 'Change the paragraph aaaaaaa on page nn to bbbbbb'.   Also that means only the Editor has to worry about which fonts to use where and all that kind of thing.  Many programmers are not good at documentation things, as you've noted.  :-)

 

Mike

 


On 10/11/2011 12:31 AM, Mike Cowlishaw wrote:

 

I see your logic but then I don't see your logic. By which I mean that it takes me back almost 40 years to my COBOL/FORTRAN internship when I was struggling to grasp the order to "complete the structured design and review before starting coding". But I lack the theoretical brilliance of folks like you, so now, as then, I often have to ponder some code and make some changes and tests to see what is really happening and what can actually be done. And to be honest, I often find that documentation is a weak and fuzzy approximation to real code behavior, especially in open source projects.  

 

Experimentation to research a new design is fine, up to a point.  As for why, do you have a copy of the Rexx book?  If so, have a read through the section "Design principles" (pp 13&14 in the 2nd Ed.).  If not, let me know and I'll send you those 2 pages.

 

 NetRexx is quite good in that respect, compared to Android where the documentation isn't just fuzzy - it's often downright wrong!  

 

I believe only one or two errors have been found, to date. 

Based on your comments here and in the code, I have the impression that 15 years ago compiler performance was an important issue that motivated some of your decisions such as the logic to skip checking superclasses and interfaces if a local method could be made to work. With modern computers being faster and more powerful by orders of magnitude would you make different choices now than back then? 

 

Well, one never has enough performance, so it's always a concern (in my view, today's computers are less responsive and waste more of my time than old ones used to -- mostly due to software bloat and people being careless about performance).  Perhaps I wouldn't weight performance as heavily now as back then.

 

The risk factor in the proposed changes might be where one is starting with a number as type Rexx which you might expect to map to the foo(int) of the current class but instead goes to the foo(String) of a superclass (assuming that's cheaper -- I forget).

PS: Is it true that Europeans have to pay a fee for each touch-and-go? 

 

Depends on the airport/airfield.  My home airfield has no landing fees of any kind.  Coventry (a commercial airport) charges £15/landing and £8 for a touch-and-go.  In France, almost all small airfields are free.  In the UK, almost any 'manned' airfield usually charges a small fee or asks for a donation to a charity, etc.
 

Mike 

On 10/10/2011 12:32 PM, Mike Cowlishaw wrote:

 

 

I agree.  I'd like a quick solution, but as Rony and Chip point out there are a lot of ramifications.  Rony's points need to be taken seriously.
 

As usual, I'll be boring and suggest that before anyone spends time publishing code they first publish the suggested changes to the documentation.  Given that, then others can then read those changes and explain any problems.

 

When everyone is happy with the documentation ... then implementation is easy, and one can concentrate on the implementation issues (performance, etc.). 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[ThSITC]

Hello Mike, all,
   does you comment below mean you're going to publish an updated *Netrexx* book (on Prentice Hall, or wherever)

Hello Kermit,
   I do personally *think* that your examples and proposed *solutions*
do go into the right directions... Thanks a lot!

Thomas.
========================================================

Am 12.10.2011 09:19, schrieb Mike Cowlishaw:

 

Mike - thanks for suggesting a very informative test case which may help people see what is happening! 
 

And thanks for a nice exposition and demo!

 
Although it seems a little unnatural to create a NetRexx method that accepts a Java type object (for local access - I do it a lot for external callbacks from Java code), one could hypothesize a case where the method is called both from Java code and NetRexx code. 

 

(e.g., the superclass is an existing Java class -- as in the original reported problem)

 

So here is my hypothetical code with a String method in a superclass that matches an "int" method in a subclass along with the results it achieved:

----------------------- code: ------------------------------------- 

<snip> 
----------------------------------------------------------------------------- 
This test sequence does not provide much new information but it may clarify the effect of the changes for some people. I think it also shows that the changed "after3.01" compiler is much more likely to compile and run programs as most programmers would expect.

Nicely demonstrated -- yes that shows the issues.  Your last sentence is actually a reminder that (as I was breaking new ground) I may have been erring on the cautious side and preferring errors to be raised in 'grey areas'.   I think your proposed change is an improvement.  Now you guys just to figure out if it might break too mauch :-).  

 
BTW, I have two copies of the book "The NetRexx Language" next to my computer and probably have a copy of the Rexx book buried somewhere nearby also.   OK.  Look forward to hearing what you think about my documentation thoughts.

Also I have not touched any documentation because I think René was correct to require an SVN lock on the manuals to reduce conflicts in updates since we cannot easily identify changes at this time. So I have been waiting to update the documents until 3.01 is final release to prevent difficult doc merges from alternate branches.  

 

Updating the doc is the job of the Project Editor -- that avoids all the merge hassles, etc.  All you have to do is present the suggested change to the existing doc, e.g., 'Change the paragraph aaaaaaa on page nn to bbbbbb'.   Also that means only the Editor has to worry about which fonts to use where and all that kind of thing.  Many programmers are not good at documentation things, as you've noted.  :-)

 

Mike

 


On 10/11/2011 12:31 AM, Mike Cowlishaw wrote:

 

I see your logic but then I don't see your logic. By which I mean that it takes me back almost 40 years to my COBOL/FORTRAN internship when I was struggling to grasp the order to "complete the structured design and review before starting coding". But I lack the theoretical brilliance of folks like you, so now, as then, I often have to ponder some code and make some changes and tests to see what is really happening and what can actually be done. And to be honest, I often find that documentation is a weak and fuzzy approximation to real code behavior, especially in open source projects.  

 

Experimentation to research a new design is fine, up to a point.  As for why, do you have a copy of the Rexx book?  If so, have a read through the section "Design principles" (pp 13&14 in the 2nd Ed.).  If not, let me know and I'll send you those 2 pages.

 

 NetRexx is quite good in that respect, compared to Android where the documentation isn't just fuzzy - it's often downright wrong!  

 

I believe only one or two errors have been found, to date. 

Based on your comments here and in the code, I have the impression that 15 years ago compiler performance was an important issue that motivated some of your decisions such as the logic to skip checking superclasses and interfaces if a local method could be made to work. With modern computers being faster and more powerful by orders of magnitude would you make different choices now than back then? 

 

Well, one never has enough performance, so it's always a concern (in my view, today's computers are less responsive and waste more of my time than old ones used to -- mostly due to software bloat and people being careless about performance).  Perhaps I wouldn't weight performance as heavily now as back then.

 

The risk factor in the proposed changes might be where one is starting with a number as type Rexx which you might expect to map to the foo(int) of the current class but instead goes to the foo(String) of a superclass (assuming that's cheaper -- I forget).

PS: Is it true that Europeans have to pay a fee for each touch-and-go? 

 

Depends on the airport/airfield.  My home airfield has no landing fees of any kind.  Coventry (a commercial airport) charges £15/landing and £8 for a touch-and-go.  In France, almost all small airfields are free.  In the UK, almost any 'manned' airfield usually charges a small fee or asks for a donation to a charity, etc.
 

Mike 

On 10/10/2011 12:32 PM, Mike Cowlishaw wrote:

 

 

I agree.  I'd like a quick solution, but as Rony and Chip point out there are a lot of ramifications.  Rony's points need to be taken seriously.
 

As usual, I'll be boring and suggest that before anyone spends time publishing code they first publish the suggested changes to the documentation.  Given that, then others can then read those changes and explain any problems.

 

When everyone is happy with the documentation ... then implementation is easy, and one can concentrate on the implementation issues (performance, etc.). 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Aviatrexx]

On 10/12/11 07:19 Mike Cowlishaw said:

> On 10/12/11 01:03 Kermit Kiser said:
>>
>> Also I have not touched any documentation because I think René was
>> correct to require an SVN lock on the manuals to reduce conflicts in
>> updates since we cannot easily identify changes at this time.  
>      
>     Updating the doc is the job of the Project Editor -- that avoids all
>     the merge hassles, etc.  All you have to do is present the suggested
>     change to the existing doc, e.g., 'Change the paragraph aaaaaaa on
>     page nn to bbbbbb'.   Also that means only the Editor has to worry
>     about which fonts to use where and all that kind of thing.  Many
>     programmers are not good at documentation things, as you've noted.  :-)

At this early stage of the Project, it also means that the editor is
the only one who will have to deal the ramifications of any decision
to change the editing software, tools, or processes.

Please send your suggested update to me in some form.  If there are
tables, diagrams, text formatting, or any other issues that can't be
adequately presented in RichText, feel free to send me a file in
MSOffice(2007), OpenOffice.org(3.3), or HTML for that matter.

All I need is to see what you would like to add, change, and delete.
There is no guarantee that's what will end up in the document, but
I'll do my best. :-)  If the ARB feels that it needs more than minor
grammatical edits, I'll return it to you with their suggestions, to
make sure that you agree.

We're feeling our way along here, so let's just try to stay flexible
for now.

-Chip-


_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Rony G. Flatscher (wu-wien)]

Hi Kermit,

warning: this is a hijacking of the names of your classes!
;)

In order to keep things apart I will try to supply two e-mails, one about the behaviour of current NetRexx which matches its current specification 3.01 ("Hijacking, Part 1 ...") and another e-Mail ("Hijacking, Part 2...") which will follow and is about the behaviour you propose and have implemented in an experimental version of NetRexx.

The current NetRexx (3.01) defines the method resolution to be more or less as follows:

• The current class is searched and if the method is found, it is used. :)
• The current class is searched and if there are multiple methods found, then an error is issued ("Error: More than one method matches the name and signature"), translation stops.
  
• The superclass is searched for a matching method, recursively up to the root class; the first found method is used (unless in that class there would be more than one method matching in name and number of matching arguments). If no method was found an appropiate error is issued (e.g. "Error: The method 'xyz()' cannot be found in class 'Subguy' or a superclass").
  

A type of Rexx means that the NetRexx translator assumes, that its value can be coerced at runtime to one of the primitive values (boolean, byte, char, short, int, long, float, double) or String (java.lang.String).

To give you more meat on the skeleton three versions of NetRexx programs follow that are executed with the current NetRexx. It is intended to show that the three classes SuperSuperguy, Superguy and Subguy are developed and used independent from each other, although Subguy subclasses Superguy, which subclasses SuperSuperguy.

The point to stress here (for the current NetRexx) is that NetRexx ignores SuperSuperguy and Superguy, if the method can be found in Subguy. This is, because a type Rexx can be coerced to any of the types the method process needs.

This actually means that the method resolution of current NetRexx is "stable" in the sense, that it is independent of the existing superclasses, which may change over time. This is to say, a NetRexx programmer can rely on the fact that NetRexx will pick the method in the current class (if one is available there) at all times, making the program independent of the superclasses of the program in question.

1. "Stage 1" consists of the following four NetRexx programs
1. -- mr.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   import netrexx.lang.RexxIO      -- allow Ask() to be referenced
   
   o=Subguy()              -- get a Subguy object
   say "enter a value to be processed:"
   val=RexxIO.ask()        -- let the user enter a value
   o.process(val)          -- process the received value
   
   parse source s; parse version v; say s "/" v
   
   
2. -- SuperSuperguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class SuperSuperguy
   
   
3. -- Superguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class Superguy extends SuperSuperguy
        method process(val=int)
            say this".process(val=int): 1/"val"="1/val
   
   
4. -- Subguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class Subguy extends Superguy
        method process(val=float)
            numeric digits 20
            say this".process(val=float): 1/"val"="1/val
   
   
   
• Running the program "mr.nrx" with the command "netrexxc -exec -keepasjava -format -replace mr.nrx SuperSuperguy.nrx Superguy.nrx Subguy.nrx
  " yields:
  
  

  enter a value to be processed:
  17
  [hidden email](val=float): 1/17=0.058823529411764705882
  Java method mr.nrx / NetRexx 3.01 25 Sep 2011
  

  
  
2. "Stage 2" consists of the following four NetRexx programs (differences bold) plus a variation of "mr.nrx" dubbed "mr2.nrx":
1. -- mr.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   import netrexx.lang.RexxIO      -- allow Ask() to be referenced
   
   o=Subguy()              -- get a Subguy object
   say "enter a value to be processed:"
   val=RexxIO.ask()        -- let the user enter a value
   o.process(val)          -- process the received value
   
   parse source s; parse version v; say s "/" v
   
   
2. -- SuperSuperguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class SuperSuperguy
   
   
3. -- Superguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class Superguy extends SuperSuperguy
        method process(val=int)
            say this".process(val=int): 1/"val"="1/val
   
   
4. -- Subguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class Subguy extends Superguy
        method process(val=float)
            numeric digits 20
            say this".process(val=float): 1/"val"="1/val
   
        method process(val=double)
            numeric digits 30
            say this".process(val=double): 1/"val"="1/val
   
   
   
5. -- mr.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   import netrexx.lang.RexxIO      -- allow Ask() to be referenced
   
   o=Subguy()              -- get a Subguy object
   say "enter a value to be processed:"
   val=RexxIO.ask()        -- let the user enter a value
   o.process(float val)    -- process the received value
   o.process(double val)   -- process the received value
   o.process(int val)      -- process the received value
   
   parse source s; parse version v; say s "/" v
   
   
• Running the program "mr.nrx" with the command "netrexxc -exec -keepasjava -format -replace mr.nrx SuperSuperguy.nrx Superguy.nrx Subguy.nrx
  " yields:
  
  

  Program mr.nrx
    8 +++ o.process(val)          -- process the received value
      +++   ^^^^^^^
      +++ Error: More than one method matches the name and signature 'Subguy.process(netrexx.lang.Rexx)'
  

  Here an error is raised as the Rexx type could be coerced to the process(float) or the process(double) method, but the programmer did not indicate which of these two methods he would want to use.
  
  
  
• Running the program "mr.nrx" with the command "netrexxc -exec -keepasjava -format -replace mr2.nrx SuperSuperguy.nrx Superguy.nrx Subguy.nrx
  " yields:
  
  

  enter a value to be processed:
  17
  [hidden email](val=float): 1/17=0.058823529411764705882
  [e-mail](val=double): 1/17=0.0588235294117647058823529411765
  [e-mail](val=float): 1/17=0.058823529411764705882
  Java method mr2.nrx / NetRexx 3.01 25 Sep 2011

  This time the program ran successfully as the invocation carried a type other than Rexx. Interestingly, the invocation of process(int) yielded the invocation of process(float)!
  
  This is even the case, although in the superclass there would be an exactly matching method process(int).
  
  Studying the documentation still makes it clear, that this is to be expected, as the current class possessing a method that can be chosen prevails the methods in the superclass.
  
  
  
3. "Stage 3" consists of the following four NetRexx programs:
1. -- mr.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   import netrexx.lang.RexxIO      -- allow Ask() to be referenced
   
   -- o=Subguy()              -- get a Subguy object
   o=Superguy()              -- get a Subguy object
   say "enter a value to be processed:"
   val=RexxIO.ask()        -- let the user enter a value
   o.process(val)          -- process the received value
   
   parse source s; parse version v; say s "/" v
   
   
2. -- SuperSuperguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class SuperSuperguy
        method process(val=String)
            say this".process(val=String):" "val="val "val.substr(0,2)="val.substring(0,2)
   
   
3. -- Superguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class Superguy extends SuperSuperguy
        method process(val=int)
            say this".process(val=int): 1/"val"="1/val
   
   
4. -- Subguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class Subguy extends Superguy
        method process(val=float)
            numeric digits 20
            say this".process(val=float): 1/"val"="1/val
   
        method process(val=double)
            numeric digits 30
            say this".process(val=double): 1/"val"="1/val
   
   
5. Running the program "mr.nrx" with the command "netrexxc -exec -keepasjava -format -replace mr.nrx SuperSuperguy.nrx Superguy.nrx Subguy.nrx" yields:
   
   • 
     

     enter a value to be processed:
     17
     [hidden email](val=int): 1/17=0.0588235294
     Java method mr.nrx / NetRexx 3.01 25 Sep 2011
     
     

     This is to be expected, as now the base class is "Superguy" having a process(int) method which gets picked (current class prevails, is used before any superclass).
     

In all three stages it can be seen that the NetRexx programmer can be sure that the method of the current class is chosen over any other methods that may be available in the superclass(es), which is what the programmer should expect, if being aware of the current NetRexx method resolution.

In this sense the method resolution of current NetRexx can be said to be stable, because independent of the superclasses.

---rony







_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Rony G. Flatscher (wu-wien)]

Hi Kermit,

warning: this is a hijacking of the names of your classes!
;)

In order to keep things apart I will try to supply two e-mails, one about the behaviour of current NetRexx which matches its current specification 3.01 ("Hijacking, Part 1 ...") and another e-Mail ("Hijacking, Part 2...") which will follow and is about the behaviour you propose and have implemented in an experimental version of NetRexx.

The experimental NetRexx defines the method resolution to be more or less as follows:

• The current class and all of its superclasses are searched for all methods that could match,
• a calculation is carried out to determine which method should be picked.
  
• No one knows how the calculation is carried out, but it is reliably carried out, and the "cheapest" method, which no one knows what it would be, will be picked from the appropriate class, which no one knows what it would be.
  ;)
  

To give you more meat on the skeleton three versions of NetRexx programs follow that are executed with the experimental NetRexx. It is intended to show that the three classes SuperSuperguy, Superguy and Subguy are developed and used independent from each other, although Subguy subclasses Superguy, which subclasses SuperSuperguy.

1. "Stage 1" consists of the following four NetRexx programs
1. -- mr.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   import netrexx.lang.RexxIO      -- allow Ask() to be referenced
   
   o=Subguy()              -- get a Subguy object
   say "enter a value to be processed:"
   val=RexxIO.ask()        -- let the user enter a value
   o.process(val)          -- process the received value
   
   parse source s; parse version v; say s "/" v
   
   
2. -- SuperSuperguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class SuperSuperguy
   
   
3. -- Superguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class Superguy extends SuperSuperguy
        method process(val=int)
            say this".process(val=int): 1/"val"="1/val
   
   
4. -- Subguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class Subguy extends Superguy
        method process(val=float)
            numeric digits 20
            say this".process(val=float): 1/"val"="1/val
   
   
   
• Running the program "mr.nrx" with the command "netrexxc -exec -keepasjava -format -replace mr.nrx SuperSuperguy.nrx Superguy.nrx Subguy.nrx
  " yields (same as current NetRexx):
  
  

  enter a value to be processed:
  17
  [hidden email](val=float): 1/17=0.058823529411764705882
  Java method mr.nrx / NetRexx 3.01 25 Sep 2011
  

  
  
2. "Stage 2" consists of the following four NetRexx programs (differences bold) plus a variation of "mr.nrx" dubbed "mr2.nrx":
1. -- mr.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   import netrexx.lang.RexxIO      -- allow Ask() to be referenced
   
   o=Subguy()              -- get a Subguy object
   say "enter a value to be processed:"
   val=RexxIO.ask()        -- let the user enter a value
   o.process(val)          -- process the received value
   
   parse source s; parse version v; say s "/" v
   
   
2. -- SuperSuperguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class SuperSuperguy
   
   
3. -- Superguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class Superguy extends SuperSuperguy
        method process(val=int)
            say this".process(val=int): 1/"val"="1/val
   
   
4. -- Subguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class Subguy extends Superguy
        method process(val=float)
            numeric digits 20
            say this".process(val=float): 1/"val"="1/val
   
        method process(val=double)
            numeric digits 30
            say this".process(val=double): 1/"val"="1/val
   
   
   
5. -- mr.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   import netrexx.lang.RexxIO      -- allow Ask() to be referenced
   
   o=Subguy()              -- get a Subguy object
   say "enter a value to be processed:"
   val=RexxIO.ask()        -- let the user enter a value
   o.process(float val)    -- process the received value
   o.process(double val)   -- process the received value
   o.process(int val)      -- process the received value
   
   parse source s; parse version v; say s "/" v
   
   
• Running the program "mr.nrx" with the command "netrexxc -exec -keepasjava -format -replace mr.nrx SuperSuperguy.nrx Superguy.nrx Subguy.nrx
  " yields (same as current NetRexx):
  
  

  Program mr.nrx
    8 +++ o.process(val)          -- process the received value
      +++   ^^^^^^^
      +++ Error: More than one method matches the name and signature 'Subguy.process(netrexx.lang.Rexx)'
  

  Here an error is raised as the Rexx type could be coerced to the process(float) or the process(double) method, but the programmer did not indicate which of these two methods he would want to use.
  
  
  
• Running the program "mr.nrx" with the command "netrexxc -exec -keepasjava -format -replace mr2.nrx SuperSuperguy.nrx Superguy.nrx Subguy.nrx
  " yields (different to current NetRexx!):
  
  

  enter a value to be processed:
  17
  [hidden email](val=float): 1/17=0.058823529411764705882
  [hidden email](val=double): 1/17=0.0588235294117647058823529411765
  [hidden email](val=int): 1/17=0.0588235294
  Java method mr2.nrx / NetRexx 3.01 25 Sep 2011
  

  This time the program ran successfully as the invocation carried a type other than Rexx. Interestingly, the invocation of process(int) yielded the invocation of process(float)!
  
  This is even the case, although in the superclass there would be an exactly matching method process(int).
  
  Studying the documentation still makes it clear, that this is to be expected, as the current class possessing a method that can be chosen prevails the methods in the superclass.
  
  
  
3. "Stage 3" consists of the following four NetRexx programs:
1. -- mr.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   import netrexx.lang.RexxIO      -- allow Ask() to be referenced
   
   -- o=Subguy()              -- get a Subguy object
   o=Superguy()              -- get a Subguy object
   say "enter a value to be processed:"
   val=RexxIO.ask()        -- let the user enter a value
   o.process(val)          -- process the received value
   
   parse source s; parse version v; say s "/" v
   
   
2. -- SuperSuperguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class SuperSuperguy
        method process(val=String)
            say this".process(val=String):" "val="val "val.substr(0,2)="val.substring(0,2)
   
   
3. -- Superguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class Superguy extends SuperSuperguy
        method process(val=int)
            say this".process(val=int): 1/"val"="1/val
   
   
4. -- Subguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class Subguy extends Superguy
        method process(val=float)
            numeric digits 20
            say this".process(val=float): 1/"val"="1/val
   
        method process(val=double)
            numeric digits 30
            say this".process(val=double): 1/"val"="1/val
   
   
5. Running the program "mr.nrx" with the command "netrexxc -exec -keepasjava -format -replace mr.nrx SuperSuperguy.nrx Superguy.nrx Subguy.nrx" yields (different to current NetRexx):
   
   • 
     

     enter a value to be processed:
     17
     [hidden email](val=String): val=17 val.substr(0,2)=17
     Java method mr.nrx / NetRexx 3.01 25 Sep 2011
     
     

     Although current class is "Superguy" now, it is not its method that gets picked (which could carry out the division!), but another method in some of its superclasses, that NetRexx thinks is better suited, because it has lesser costs. (Although no one seems to be able to explain that.)
     

Unlike the current NetRexx the experimental version seems to be "fragile" in the sense, that method resolution is not stable anymore. I.e. if a superclass gets changed later on, and a cheaper method can be picked, then on the next translation that cheaper method in one of the superclasses will get executed instead!

---rony


_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Kermit Kiser]

Rony -

Thanks for providing executable code for us hands-on types!

Rony & all -

I have modified the hijacked title as it was getting a little long, etc.

I am not sure I can totally separate my response by versions, as some of my comments here directly bear on conclusions in part 2.

First, please forgive me if this background is old news to you, but at the Java 1.5 level, Sun began to convert some library modules to replace "String" parameters with "CharSequence" parameters and add "appendable" interfaces to them. This significantly modified the IO classes such as Writers and Streams. It did not cause any problems for Java programs because Java has very strict algorithms for method selection and inheritance. Unfortunately it severely negatively impacted NetRexx programs which can no longer extend those classes nor access the new append methods and cannot even easily access the common "write(String)" methods because the special case "write(int)" methods make them invisible as reported here recently in this thread by Alan and KP. These are the problems that I have tried to address with my proposed changes to NetRexx method resolution. I  don't know about anyone else but I don't appreciate being told that we are not having real problems.

Here is a test program which does simple stuff that any Java programmer can do with no problem and the output you get if you try to compile it with NetRexx 3.01:
---------------------------------------------------------
mystream=BufferedWriter(StringWriter())

mystream.write("something")
mystream.append("something")

class newstream extends PrintStream
    method newstream
        super("somefile")
----------------------------------------------------------
Program charseqtests3.nrx
[C:\NetRexx\testing\charseqtests3.nrx 3 1 8] Error: Cannot convert constant value 'something' to type 'int'
[C:\NetRexx\testing\charseqtests3.nrx 4 10 6] Error: More than one method matches the name and signature 'java.io.Writer.append(java.lang.String)'
 
  === class newstream ===
    constructor newstream()
      signals FileNotFoundException
[C:\NetRexx\testing\charseqtests3.nrx 6 7 9] Error: Class is not abstract, yet it does not implement method 'append(CharSequence) returns java.lang.Appendable' from abstract class 'java.lang.Appendable'
[C:\NetRexx\testing\charseqtests3.nrx 6 7 9] Error: Class is not abstract, yet it does not implement method 'append(CharSequence,int,int) returns java.lang.Appendable' from abstract class 'java.lang.Appendable'
[C:\NetRexx\testing\charseqtests3.nrx 6 7 9] Error: Class is not abstract, yet it does not implement method 'append(char) returns java.lang.Appendable' from abstract class 'java.lang.Appendable'
Compilation of 'charseqtests3.nrx' failed [2 classes, 5 errors]
 -----------------------------------------------------------------------------------------------

The experimental "after3.01" NetRexx translator with enhanced method selection compiles the above program correctly and it runs without error.

BTW:  The method selection algorithm overview listed by Rony is not precisely correct as it omits the scan of interface classes during the recursive superclass scan and the "unknown" calculation that is performed to decide if a method is selected or an "ambiguous" message is issued.

 If I understand the idea of the scenario proposed by Rony, each class is maintained by a different developer without collaboration. But there seems to be a missing test case at stage 3 - Suppose that not the developer of SuperSuperguy but the developer of Superguy adds the new String handling method? :

method process(val=String)
         say this".process(val=String):" "val="val "val.substr(0,2)="val.substring(0,2)

Here is the output of the mr.nrx program after compiling with the 3.01 translator:
-----------------------------------------------------------------------
enter a value to be processed:
17
[hidden email](val=String): val=17 val.substr(0,2)=17
Java method mr.nrx / NetRexx 3.00 11 Jun 2011
------------------------------------------------------------------------

Wait! You mean the "stable" current NetRexx translator changed the method called when the superclass programmer changed his class? Yep, because NetRexx is not Java and when you allow NetRexx to convert arguments and select methods for you, that selection can be changed by the actions of a superclass programmer!

Now let's look at part two.

-- Kermit


On 10/12/2011 12:16 PM, Rony G. Flatscher wrote:

Hi Kermit,

warning: this is a hijacking of the names of your classes!
;)

In order to keep things apart I will try to supply two e-mails, one about the behaviour of current NetRexx which matches its current specification 3.01 ("Hijacking, Part 1 ...") and another e-Mail ("Hijacking, Part 2...") which will follow and is about the behaviour you propose and have implemented in an experimental version of NetRexx.

The current NetRexx (3.01) defines the method resolution to be more or less as follows:

• The current class is searched and if the method is found, it is used. :)
• The current class is searched and if there are multiple methods found, then an error is issued ("Error: More than one method matches the name and signature"), translation stops.
  
• The superclass is searched for a matching method, recursively up to the root class; the first found method is used (unless in that class there would be more than one method matching in name and number of matching arguments). If no method was found an appropiate error is issued (e.g. "Error: The method 'xyz()' cannot be found in class 'Subguy' or a superclass").
  

A type of Rexx means that the NetRexx translator assumes, that its value can be coerced at runtime to one of the primitive values (boolean, byte, char, short, int, long, float, double) or String (java.lang.String).

To give you more meat on the skeleton three versions of NetRexx programs follow that are executed with the current NetRexx. It is intended to show that the three classes SuperSuperguy, Superguy and Subguy are developed and used independent from each other, although Subguy subclasses Superguy, which subclasses SuperSuperguy.

The point to stress here (for the current NetRexx) is that NetRexx ignores SuperSuperguy and Superguy, if the method can be found in Subguy. This is, because a type Rexx can be coerced to any of the types the method process needs.

This actually means that the method resolution of current NetRexx is "stable" in the sense, that it is independent of the existing superclasses, which may change over time. This is to say, a NetRexx programmer can rely on the fact that NetRexx will pick the method in the current class (if one is available there) at all times, making the program independent of the superclasses of the program in question.

1. "Stage 1" consists of the following four NetRexx programs
1. -- mr.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   import netrexx.lang.RexxIO      -- allow Ask() to be referenced
   
   o=Subguy()              -- get a Subguy object
   say "enter a value to be processed:"
   val=RexxIO.ask()        -- let the user enter a value
   o.process(val)          -- process the received value
   
   parse source s; parse version v; say s "/" v
   
   
2. -- SuperSuperguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class SuperSuperguy
   
   
3. -- Superguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class Superguy extends SuperSuperguy
        method process(val=int)
            say this".process(val=int): 1/"val"="1/val
   
   
4. -- Subguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class Subguy extends Superguy
        method process(val=float)
            numeric digits 20
            say this".process(val=float): 1/"val"="1/val
   
   
   
• Running the program "mr.nrx" with the command "netrexxc -exec -keepasjava -format -replace mr.nrx SuperSuperguy.nrx Superguy.nrx Subguy.nrx
  " yields:
  
  

  enter a value to be processed:
  17
  [hidden email](val=float): 1/17=0.058823529411764705882
  Java method mr.nrx / NetRexx 3.01 25 Sep 2011
  

  
  
2. "Stage 2" consists of the following four NetRexx programs (differences bold) plus a variation of "mr.nrx" dubbed "mr2.nrx":
1. -- mr.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   import netrexx.lang.RexxIO      -- allow Ask() to be referenced
   
   o=Subguy()              -- get a Subguy object
   say "enter a value to be processed:"
   val=RexxIO.ask()        -- let the user enter a value
   o.process(val)          -- process the received value
   
   parse source s; parse version v; say s "/" v
   
   
2. -- SuperSuperguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class SuperSuperguy
   
   
3. -- Superguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class Superguy extends SuperSuperguy
        method process(val=int)
            say this".process(val=int): 1/"val"="1/val
   
   
4. -- Subguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class Subguy extends Superguy
        method process(val=float)
            numeric digits 20
            say this".process(val=float): 1/"val"="1/val
   
        method process(val=double)
            numeric digits 30
            say this".process(val=double): 1/"val"="1/val
   
   
   
5. -- mr.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   import netrexx.lang.RexxIO      -- allow Ask() to be referenced
   
   o=Subguy()              -- get a Subguy object
   say "enter a value to be processed:"
   val=RexxIO.ask()        -- let the user enter a value
   o.process(float val)    -- process the received value
   o.process(double val)   -- process the received value
   o.process(int val)      -- process the received value
   
   parse source s; parse version v; say s "/" v
   
   
• Running the program "mr.nrx" with the command "netrexxc -exec -keepasjava -format -replace mr.nrx SuperSuperguy.nrx Superguy.nrx Subguy.nrx
  " yields:
  
  

  Program mr.nrx
    8 +++ o.process(val)          -- process the received value
      +++   ^^^^^^^
      +++ Error: More than one method matches the name and signature 'Subguy.process(netrexx.lang.Rexx)'
  

  Here an error is raised as the Rexx type could be coerced to the process(float) or the process(double) method, but the programmer did not indicate which of these two methods he would want to use.
  
  
  
• Running the program "mr.nrx" with the command "netrexxc -exec -keepasjava -format -replace mr2.nrx SuperSuperguy.nrx Superguy.nrx Subguy.nrx
  " yields:
  
  

  enter a value to be processed:
  17
  [hidden email](val=float): 1/17=0.058823529411764705882
  [e-mail](val=double): 1/17=0.0588235294117647058823529411765
  [e-mail](val=float): 1/17=0.058823529411764705882
  Java method mr2.nrx / NetRexx 3.01 25 Sep 2011

  This time the program ran successfully as the invocation carried a type other than Rexx. Interestingly, the invocation of process(int) yielded the invocation of process(float)!
  
  This is even the case, although in the superclass there would be an exactly matching method process(int).
  
  Studying the documentation still makes it clear, that this is to be expected, as the current class possessing a method that can be chosen prevails the methods in the superclass.
  
  
  
3. "Stage 3" consists of the following four NetRexx programs:
1. -- mr.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   import netrexx.lang.RexxIO      -- allow Ask() to be referenced
   
   -- o=Subguy()              -- get a Subguy object
   o=Superguy()              -- get a Subguy object
   say "enter a value to be processed:"
   val=RexxIO.ask()        -- let the user enter a value
   o.process(val)          -- process the received value
   
   parse source s; parse version v; say s "/" v
   
   
2. -- SuperSuperguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class SuperSuperguy
        method process(val=String)
            say this".process(val=String):" "val="val "val.substr(0,2)="val.substring(0,2)
   
   
3. -- Superguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class Superguy extends SuperSuperguy
        method process(val=int)
            say this".process(val=int): 1/"val"="1/val
   
   
4. -- Subguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class Subguy extends Superguy
        method process(val=float)
            numeric digits 20
            say this".process(val=float): 1/"val"="1/val
   
        method process(val=double)
            numeric digits 30
            say this".process(val=double): 1/"val"="1/val
   
   
5. Running the program "mr.nrx" with the command "netrexxc -exec -keepasjava -format -replace mr.nrx SuperSuperguy.nrx Superguy.nrx Subguy.nrx" yields:
   
   • 
     

     enter a value to be processed:
     17
     [hidden email](val=int): 1/17=0.0588235294
     Java method mr.nrx / NetRexx 3.01 25 Sep 2011
     
     

     This is to be expected, as now the base class is "Superguy" having a process(int) method which gets picked (current class prevails, is used before any superclass).
     

In all three stages it can be seen that the NetRexx programmer can be sure that the method of the current class is chosen over any other methods that may be available in the superclass(es), which is what the programmer should expect, if being aware of the current NetRexx method resolution.

In this sense the method resolution of current NetRexx can be said to be stable, because independent of the superclasses.

---rony

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Kermit Kiser]

Hi all -

Here are some more thoughts on hijacking:

For reasons of documentation versioning issues no doc changes have been made yet, but I did describe the NetRexx method selection algorithms on the list a few days ago. Here is an updated summary (overview) of those algorithms showing the differences:

The current (3.01) method selection logic is a recursive algorithm:

1) If any methods in the current class can be used, select the best fit (least cost algorithm created by Mike) and use it.
2) If any methods in the superclass can be used, select the best fit using this algorithm and use it.
3) If any methods in interfaces can be used, select the best fit (least cost) and use it.

The proposed (after 3.01) method selection logic is the following recursive algorithm:

1) If there is an exact match in the current class, use it.
2) If any methods in the current class can be used, save the best fit and it's cost.
3) If there is an exact match in the superclass, use it.
4) If any superclass methods can be used, save the best fit using this algorithm and it's cost.
5) If any interface methods can be used, save the best fit and it's cost.
6) Select the best fit (least cost) of the saved methods and use it. Ties go to the first method found in the inheritance tree just as in Java.

Some more details: If two methods with the same cost are found at any level, an ambiguous message is issued in either algorithm above. The cost calculation used in the proposed algorithm is the same 15 year old calculation as used in the current algorithm with one minor exception: If a tested method is an interface method, either 1 or 2 points are added to the calculated cost. This prevents a cost conflict between an interface method and it's concrete implementation which otherwise would have the exact same signature and cost. (There are two separate add values because the interface methods are checked twice.)

I will try a rewrite of the much more detailed algorithm described in the language manual when there is time. Meanwhile it should be clear that the following note from that manual is NOT true with the proposed selection algorithm:

"Note: When a method is found in a class, superclasses of that class are not searched for methods, even though a lower-cost method may exist in a superclass."

There seem to be some copy/paste errors in the scenarios listed below, so I won't say anything more except to reiterate that even the current translators can pick a different method on a recompile if the external classes have changed and I believe the new algorithm is less fragile (more stable and robust) than the old one.

-- Kermit


On 10/12/2011 12:28 PM, Rony G. Flatscher wrote:

Hi Kermit,

warning: this is a hijacking of the names of your classes!
;)

In order to keep things apart I will try to supply two e-mails, one about the behaviour of current NetRexx which matches its current specification 3.01 ("Hijacking, Part 1 ...") and another e-Mail ("Hijacking, Part 2...") which will follow and is about the behaviour you propose and have implemented in an experimental version of NetRexx.

The experimental NetRexx defines the method resolution to be more or less as follows:

• The current class and all of its superclasses are searched for all methods that could match,
• a calculation is carried out to determine which method should be picked.
  
• No one knows how the calculation is carried out, but it is reliably carried out, and the "cheapest" method, which no one knows what it would be, will be picked from the appropriate class, which no one knows what it would be.
  ;)
  

To give you more meat on the skeleton three versions of NetRexx programs follow that are executed with the experimental NetRexx. It is intended to show that the three classes SuperSuperguy, Superguy and Subguy are developed and used independent from each other, although Subguy subclasses Superguy, which subclasses SuperSuperguy.

1. "Stage 1" consists of the following four NetRexx programs
1. -- mr.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   import netrexx.lang.RexxIO      -- allow Ask() to be referenced
   
   o=Subguy()              -- get a Subguy object
   say "enter a value to be processed:"
   val=RexxIO.ask()        -- let the user enter a value
   o.process(val)          -- process the received value
   
   parse source s; parse version v; say s "/" v
   
   
2. -- SuperSuperguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class SuperSuperguy
   
   
3. -- Superguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class Superguy extends SuperSuperguy
        method process(val=int)
            say this".process(val=int): 1/"val"="1/val
   
   
4. -- Subguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class Subguy extends Superguy
        method process(val=float)
            numeric digits 20
            say this".process(val=float): 1/"val"="1/val
   
   
   
• Running the program "mr.nrx" with the command "netrexxc -exec -keepasjava -format -replace mr.nrx SuperSuperguy.nrx Superguy.nrx Subguy.nrx
  " yields (same as current NetRexx):
  
  

  enter a value to be processed:
  17
  [hidden email](val=float): 1/17=0.058823529411764705882
  Java method mr.nrx / NetRexx 3.01 25 Sep 2011
  

  
  
2. "Stage 2" consists of the following four NetRexx programs (differences bold) plus a variation of "mr.nrx" dubbed "mr2.nrx":
1. -- mr.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   import netrexx.lang.RexxIO      -- allow Ask() to be referenced
   
   o=Subguy()              -- get a Subguy object
   say "enter a value to be processed:"
   val=RexxIO.ask()        -- let the user enter a value
   o.process(val)          -- process the received value
   
   parse source s; parse version v; say s "/" v
   
   
2. -- SuperSuperguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class SuperSuperguy
   
   
3. -- Superguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class Superguy extends SuperSuperguy
        method process(val=int)
            say this".process(val=int): 1/"val"="1/val
   
   
4. -- Subguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class Subguy extends Superguy
        method process(val=float)
            numeric digits 20
            say this".process(val=float): 1/"val"="1/val
   
        method process(val=double)
            numeric digits 30
            say this".process(val=double): 1/"val"="1/val
   
   
   
5. -- mr.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   import netrexx.lang.RexxIO      -- allow Ask() to be referenced
   
   o=Subguy()              -- get a Subguy object
   say "enter a value to be processed:"
   val=RexxIO.ask()        -- let the user enter a value
   o.process(float val)    -- process the received value
   o.process(double val)   -- process the received value
   o.process(int val)      -- process the received value
   
   parse source s; parse version v; say s "/" v
   
   
• Running the program "mr.nrx" with the command "netrexxc -exec -keepasjava -format -replace mr.nrx SuperSuperguy.nrx Superguy.nrx Subguy.nrx
  " yields (same as current NetRexx):
  
  

  Program mr.nrx
    8 +++ o.process(val)          -- process the received value
      +++   ^^^^^^^
      +++ Error: More than one method matches the name and signature 'Subguy.process(netrexx.lang.Rexx)'
  

  Here an error is raised as the Rexx type could be coerced to the process(float) or the process(double) method, but the programmer did not indicate which of these two methods he would want to use.
  
  
  
• Running the program "mr.nrx" with the command "netrexxc -exec -keepasjava -format -replace mr2.nrx SuperSuperguy.nrx Superguy.nrx Subguy.nrx
  " yields (different to current NetRexx!):
  
  

  enter a value to be processed:
  17
  [hidden email](val=float): 1/17=0.058823529411764705882
  [hidden email](val=double): 1/17=0.0588235294117647058823529411765
  [hidden email](val=int): 1/17=0.0588235294
  Java method mr2.nrx / NetRexx 3.01 25 Sep 2011
  

  This time the program ran successfully as the invocation carried a type other than Rexx. Interestingly, the invocation of process(int) yielded the invocation of process(float)!
  
  This is even the case, although in the superclass there would be an exactly matching method process(int).
  
  Studying the documentation still makes it clear, that this is to be expected, as the current class possessing a method that can be chosen prevails the methods in the superclass.
  
  
  
3. "Stage 3" consists of the following four NetRexx programs:
1. -- mr.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   import netrexx.lang.RexxIO      -- allow Ask() to be referenced
   
   -- o=Subguy()              -- get a Subguy object
   o=Superguy()              -- get a Subguy object
   say "enter a value to be processed:"
   val=RexxIO.ask()        -- let the user enter a value
   o.process(val)          -- process the received value
   
   parse source s; parse version v; say s "/" v
   
   
2. -- SuperSuperguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class SuperSuperguy
        method process(val=String)
            say this".process(val=String):" "val="val "val.substr(0,2)="val.substring(0,2)
   
   
3. -- Superguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class Superguy extends SuperSuperguy
        method process(val=int)
            say this".process(val=int): 1/"val"="1/val
   
   
4. -- Subguy.nrx, version 1.0, method resolution, stage 1 example, rgf, 2011-10-12
   
   Class Subguy extends Superguy
        method process(val=float)
            numeric digits 20
            say this".process(val=float): 1/"val"="1/val
   
        method process(val=double)
            numeric digits 30
            say this".process(val=double): 1/"val"="1/val
   
   
5. Running the program "mr.nrx" with the command "netrexxc -exec -keepasjava -format -replace mr.nrx SuperSuperguy.nrx Superguy.nrx Subguy.nrx" yields (different to current NetRexx):
   
   • 
     

     enter a value to be processed:
     17
     [hidden email](val=String): val=17 val.substr(0,2)=17
     Java method mr.nrx / NetRexx 3.01 25 Sep 2011
     
     

     Although current class is "Superguy" now, it is not its method that gets picked (which could carry out the division!), but another method in some of its superclasses, that NetRexx thinks is better suited, because it has lesser costs. (Although no one seems to be able to explain that.)
     

Unlike the current NetRexx the experimental version seems to be "fragile" in the sense, that method resolution is not stable anymore. I.e. if a superclass gets changed later on, and a cheaper method can be picked, then on the next translation that cheaper method in one of the superclasses will get executed instead!

---rony

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Rony G. Flatscher (wu-wien)]

Kermit,

sorry for the late (and brief) answers/comments, have been in a sort of "land under water" mode, which will last a while, I am afraid.

On 13.10.2011 22:51, Kermit Kiser wrote:

I have modified the hijacked title as it was getting a little long, etc.

I am not sure I can totally separate my response by versions, as some of my comments here directly bear on conclusions in part 2.

First, please forgive me if this background is old news to you, but at the Java 1.5 level, Sun began to convert some library modules to replace "String" parameters with "CharSequence" parameters and add "appendable" interfaces to them. This significantly modified the IO classes such as Writers and Streams. It did not cause any problems for Java programs because Java has very strict algorithms for method selection and inheritance.

Well, whatever changes Sun/Oracle adds to Java, they always try to remain backwardly compatible. Hence I would be interested to learn about changes in the IO classes that yielded incompatibilities with Java programs.

Unfortunately it severely negatively impacted NetRexx programs which can no longer extend those classes nor access the new append methods and cannot even easily access the common "write(String)" methods because the special case "write(int)" methods make them invisible as reported here recently in this thread by Alan and KP.

The "Alan-issue" is not an issue/bug of NetRexx IMHO, as NetRexx behaves according to its specifications: it picks a matching method in the current class.

These are the problems that I have tried to address with my proposed changes to NetRexx method resolution. I  don't know about anyone else but I don't appreciate being told that we are not having real problems.

Here is a test program which does simple stuff that any Java programmer can do with no problem and the output you get if you try to compile it with NetRexx 3.01:
---------------------------------------------------------
mystream=BufferedWriter(StringWriter())

mystream.write("something")

The above is the "Alan-issue": 

• casting to the superclass allows NetRexx to regard the superclass as the "current class" and hence is allowed to pick a matching method there (or one of its superclasses), like:
     (Writer mystream).write("something")

mystream.append("something")

This is a type mismatch as the type "something" is not of type CharSequence, casting the argument resolves this error message, like:
   mystream.append(CharSequence "something")

class newstream extends PrintStream
    method newstream
        super("somefile")
----------------------------------------------------------
Program charseqtests3.nrx
[C:\NetRexx\testing\charseqtests3.nrx 3 1 8] Error: Cannot convert constant value 'something' to type 'int'

Correct, BufferedWriter defines a method 'write(int)', but not a method 'write(String)', which is defined in its superclass Writer.

[C:\NetRexx\testing\charseqtests3.nrx 4 10 6] Error: More than one method matches the name and signature 'java.io.Writer.append(java.lang.String)'

The error message in this case is misleading as there is no method: 'java.io.Writer.append(java.lang.String)' , instead there are 'java.io.Writer.append(char)' or 'java.io.Writer.append(CharSequence)' which NetRexx thinks are candidates. [Wondering a little bit why NetRexx would consider the interface type CharSequence to be equivalent to java.lang.String, which merely implements that very same interface.)

---- ---- ----

 
  === class newstream ===
    constructor newstream()
      signals FileNotFoundException
[C:\NetRexx\testing\charseqtests3.nrx 6 7 9] Error: Class is not abstract, yet it does not implement method 'append(CharSequence) returns java.lang.Appendable' from abstract class 'java.lang.Appendable'
[C:\NetRexx\testing\charseqtests3.nrx 6 7 9] Error: Class is not abstract, yet it does not implement method 'append(CharSequence,int,int) returns java.lang.Appendable' from abstract class 'java.lang.Appendable'
[C:\NetRexx\testing\charseqtests3.nrx 6 7 9] Error: Class is not abstract, yet it does not implement method 'append(char) returns java.lang.Appendable' from abstract class 'java.lang.Appendable'
Compilation of 'charseqtests3.nrx' failed [2 classes, 5 errors]
 -----------------------------------------------------------------------------------------------

These error messages seem to be wrong and indicate that there is somewhere a problem in the current NetRexx algorithms resolving constructor method demands, as the superclass is concrete and implements all of the interfaces, such that the extending class has no need to implement them.  So the current NetRexx should not issue these error messages and a bug report is in place.

However, this does not mandate that the method resolution rules of the current NetRexx needs to be totally changed, introducing a totally different behaviour, and one, that cannot be predicted by NetRexx programmers.

The experimental "after3.01" NetRexx translator with enhanced method selection compiles the above program correctly and it runs without error.

BTW:  The method selection algorithm overview listed by Rony is not precisely correct as it omits the scan of interface classes during the recursive superclass scan and the "unknown" calculation that is performed to decide if a method is selected or an "ambiguous" message is issued.

 If I understand the idea of the scenario proposed by Rony, each class is maintained by a different developer without collaboration. But there seems to be a missing test case at stage 3 - Suppose that not the developer of SuperSuperguy but the developer of Superguy adds the new String handling method? :

method process(val=String)
         say this".process(val=String):" "val="val "val.substr(0,2)="val.substring(0,2)

Here is the output of the mr.nrx program after compiling with the 3.01 translator:
-----------------------------------------------------------------------
enter a value to be processed:
17
[hidden email](val=String): val=17 val.substr(0,2)=17
Java method mr.nrx / NetRexx 3.00 11 Jun 2011
------------------------------------------------------------------------

Wait! You mean the "stable" current NetRexx translator changed the method called when the superclass programmer changed his class? Yep, because NetRexx is not Java and when you allow NetRexx to convert arguments and select methods for you, that selection can be changed by the actions of a superclass programmer!

Right! You pinpoint to the following observation: the method NetRexx picks needs not to be the one the programmer expects to be picked. The assumption, that the cost based method picking always is identical to the method the NetRexx programmer's *thinks* that gets picked, is not necessarily the same.

What happens is a "method-picking guessing" by the translator using some cost-based algorithm, which ensures reproducibllity of method picking. It does not (and cannot) assure/assert, that NetRexx will always pick the method the NetRexx programmer wishes to be picked. For that reason it is always necessary, that NetRexx programmers are aware of this, such that they can explicitly cast arguments to methods where the casts narrow the pickable method down to the one the NetRexx programmer wishes to be picked.

This is BTW true for the experimental NetRexx as well.

---rony

P.S.: W.r.t. to the CharSequence interface: it would be a meaningful enhancement to extend the NetRexx conversion rules to cover CharSequence explicitly as well. Probably its costs should be different to String conversions to not get have the same minimum costs as the String-argument versions (which would lead to an error message of NetRexx to have the NetRexx programmer decide which method it should pick).




_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Rony G. Flatscher (wu-wien)]

On 13.10.2011 22:59, Kermit Kiser wrote:

Hi all -

Here are some more thoughts on hijacking:

For reasons of documentation versioning issues no doc changes have been made yet, but I did describe the NetRexx method selection algorithms on the list a few days ago. Here is an updated summary (overview) of those algorithms showing the differences:

The current (3.01) method selection logic is a recursive algorithm:

1) If any methods in the current class can be used, select the best fit (least cost algorithm created by Mike) and use it.
2) If any methods in the superclass can be used, select the best fit using this algorithm and use it.
3) If any methods in interfaces can be used, select the best fit (least cost) and use it.

The proposed (after 3.01) method selection logic is the following recursive algorithm:

1) If there is an exact match in the current class, use it.
2) If any methods in the current class can be used, save the best fit and it's cost.
3) If there is an exact match in the superclass, use it.
4) If any superclass methods can be used, save the best fit using this algorithm and it's cost.
5) If any interface methods can be used, save the best fit and it's cost.
6) Select the best fit (least cost) of the saved methods and use it. Ties go to the first method found in the inheritance tree just as in Java.

Some more details: If two methods with the same cost are found at any level, an ambiguous message is issued in either algorithm above. The cost calculation used in the proposed algorithm is the same 15 year old calculation as used in the current algorithm with one minor exception: If a tested method is an interface method, either 1 or 2 points are added to the calculated cost. This prevents a cost conflict between an interface method and it's concrete implementation which otherwise would have the exact same signature and cost. (There are two separate add values because the interface methods are checked twice.)

I will try a rewrite of the much more detailed algorithm described in the language manual when there is time. Meanwhile it should be clear that the following note from that manual is NOT true with the proposed selection algorithm:

"Note: When a method is found in a class, superclasses of that class are not searched for methods, even though a lower-cost method may exist in a superclass."

The above is the fundamental change in the method resolution, and as such in the behaviour of NetRexx, which should be thought out. Also, it is a strong indicator for me, that Mike has thoughtfully devised this behaviour, as otherwise he would not explicitly make the reader aware of this important and fundamental property of the method resolution rules.

There seem to be some copy/paste errors in the scenarios listed below, so I won't say anything more except to reiterate that even the current translators can pick a different method on a recompile if the external classes have changed and I believe the new algorithm is less fragile (more stable and robust) than the old one.

There is an important distinction here: if this happens, it only can happen in the *current class*, if the alternate methods have different costs.

This change would remove a fundamental behaviour from NetRexx. This means among other things that *one can never be sure* from that moment on that the picked methods on a retranslate won't be totally different, as any time any superclass may qualify for such a change in behaviour.

---rony








_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Patric Bechtel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rony G. Flatscher schrieb am 15.10.2011 21:48:

>
> On 13.10.2011 22:59, Kermit Kiser wrote:
>> Hi all -
>>
>> Here are some more thoughts on hijacking:
>>
>> For reasons of documentation versioning issues no doc changes
>> have been made yet, but I did describe the NetRexx method
>> selection algorithms on the list a few days ago. Here is an
>> updated summary (overview) of those algorithms showing the
>> differences:
>>
>> The current (3.01) method selection logic is a recursive
>> algorithm:
>>
>> 1) If any methods in the current class can be used, select the
>> best fit (least cost algorithm created by Mike) and use it. 2) If
>> any methods in the superclass can be used, select the best fit
>> using this algorithm and use it. 3) If any methods in interfaces
>> can be used, select the best fit (least cost) and use it.
>>
>> The proposed (after 3.01) method selection logic is the
>> following recursive algorithm:
>>
>> 1) If there is an exact match in the current class, use it. 2) If
>> any methods in the current class can be used, save the best fit
>> and it's cost. 3) If there is an exact match in the superclass,
>> use it. 4) If any superclass methods can be used, save the best
>> fit using this algorithm and it's cost. 5) If any interface
>> methods can be used, save the best fit and it's cost. 6) Select
>> the best fit (least cost) of the saved methods and use it. Ties
>> go to the first method found in the inheritance tree just as in
>> Java.
>>
>> Some more details: If two methods with the same cost are found at
>> any level, an ambiguous message is issued in either algorithm
>> above. The cost calculation used in the proposed algorithm is the
>> same 15 year old calculation as used in the current algorithm
>> with one minor exception: If a tested method is an interface
>> method, either 1 or 2 points are added to the calculated cost.
>> This prevents a cost conflict between an interface method and
>> it's concrete implementation which otherwise would have the exact
>> same signature and cost. (There are two separate add values
>> because the interface methods are checked twice.)
>>
>> I will try a rewrite of the much more detailed algorithm
>> described in the language manual when there is time. Meanwhile it
>> should be clear that the following note from that manual is NOT
>> true with the proposed selection algorithm:
>>
>> "Note: When a method is found in a class, superclasses of that
>> class are not searched for methods, even though a lower-cost
>> method may exist in a superclass."
> The above is the fundamental change in the method resolution, and
> as such in the behaviour of NetRexx, which should be thought out.
> Also, it is a strong indicator for me, that Mike has thoughtfully
> devised this behaviour, as otherwise he would not explicitly make
> the reader aware of this important and fundamental property of the
> method resolution rules.
>
>> There seem to be some copy/paste errors in the scenarios listed
>> below, so I won't say anything more except to reiterate that even
>> the current translators can pick a different method on a
>> recompile if the external classes have changed and I believe the
>> new algorithm is less fragile (more stable and robust) than the
>> old one.
> There is an important distinction here: if this happens, it only
> can happen in the *current class*, if the alternate methods have
> different costs.
>
> This change would remove a fundamental behaviour from NetRexx.
> This means among other things that *one can never be sure* from
> that moment on that the picked methods on a retranslate won't be
> totally different, as any time any superclass may qualify for such
> a change in behaviour.

- From a oo view of things, the method resolution should be exactly as
Kermit implemented it: it doesn't matter *which* class exactly
implements which method, as that might be subject to change anytime.
The external view upon objects is the counting one, which always
includes all methods of all superclasses. This is the view that
matters, and if a method can be found within them with exact match or
interface match, it should be chosen.

Kudos to Kermit for fixing that behaviour now. There's still some work
to do (interfaces of parameters such as CharSequence and char->String
coercion having priority over Rexx conversion), but this is really the
way to go.

- --
cu, Patric
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: GnuPT 2.5.2

iEYEARECAAYFAk6aARUACgkQfGgGu8y7ypA5iQCg+jpzJ0fXbtsxIAaatcDzIDaA
O8IAoOi9oaAb23ViQlFiCopcRtaGPkZf
=NYZx
-----END PGP SIGNATURE-----

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[George Hovey-2]

Rony,

A small point you may have missed.  You write

"The above is the fundamental change in the method resolution, and as such in the behaviour of NetRexx, which should be thought out. Also, it is a strong indicator for me, that Mike has thoughtfully devised this behaviour, as otherwise he would not explicitly make the reader aware of this important and fundamental property of the method resolution rules."  (My emphasis).

But on Oct 11 Kermit, in an exchange with Mike, gave an extended example expounding his point of view, and Mike replied (Oct 12):

'Nicely demonstrated -- yes that shows the issues.  Your last sentence is actually a reminder that (as I was breaking new ground) I may have been erring on the cautious side and preferring errors to be raised in 'grey areas'.   I think your proposed change is an improvement.  Now you guys just to figure out if it might break too mauch :-).

Can this mean anything other than that Mike regards changes in this area a proper subject for discussion, and at least tentatively, to view Kermit's idea favorably?

Regards,
George

On Sat, Oct 15, 2011 at 3:48 PM, Rony G. Flatscher <[hidden email]> wrote:

On <a href="tel:13.10.2011" value="[phone]" target="_blank">13.10.2011 22:59, Kermit Kiser wrote:

Hi all -

Here are some more thoughts on hijacking:

For reasons of documentation versioning issues no doc changes have been made yet, but I did describe the NetRexx method selection algorithms on the list a few days ago. Here is an updated summary (overview) of those algorithms showing the differences:

The current (3.01) method selection logic is a recursive algorithm:

1) If any methods in the current class can be used, select the best fit (least cost algorithm created by Mike) and use it.
2) If any methods in the superclass can be used, select the best fit using this algorithm and use it.
3) If any methods in interfaces can be used, select the best fit (least cost) and use it.

The proposed (after 3.01) method selection logic is the following recursive algorithm:

1) If there is an exact match in the current class, use it.
2) If any methods in the current class can be used, save the best fit and it's cost.
3) If there is an exact match in the superclass, use it.
4) If any superclass methods can be used, save the best fit using this algorithm and it's cost.
5) If any interface methods can be used, save the best fit and it's cost.
6) Select the best fit (least cost) of the saved methods and use it. Ties go to the first method found in the inheritance tree just as in Java.

Some more details: If two methods with the same cost are found at any level, an ambiguous message is issued in either algorithm above. The cost calculation used in the proposed algorithm is the same 15 year old calculation as used in the current algorithm with one minor exception: If a tested method is an interface method, either 1 or 2 points are added to the calculated cost. This prevents a cost conflict between an interface method and it's concrete implementation which otherwise would have the exact same signature and cost. (There are two separate add values because the interface methods are checked twice.)

I will try a rewrite of the much more detailed algorithm described in the language manual when there is time. Meanwhile it should be clear that the following note from that manual is NOT true with the proposed selection algorithm:

"Note: When a method is found in a class, superclasses of that class are not searched for methods, even though a lower-cost method may exist in a superclass."

The above is the fundamental change in the method resolution, and as such in the behaviour of NetRexx, which should be thought out. Also, it is a strong indicator for me, that Mike has thoughtfully devised this behaviour, as otherwise he would not explicitly make the reader aware of this important and fundamental property of the method resolution rules.

There seem to be some copy/paste errors in the scenarios listed below, so I won't say anything more except to reiterate that even the current translators can pick a different method on a recompile if the external classes have changed and I believe the new algorithm is less fragile (more stable and robust) than the old one.

There is an important distinction here: if this happens, it only can happen in the *current class*, if the alternate methods have different costs.

This change would remove a fundamental behaviour from NetRexx. This means among other things that *one can never be sure* from that moment on that the picked methods on a retranslate won't be totally different, as any time any superclass may qualify for such a change in behaviour.

---rony

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Mike Cowlishaw]

 

A small point you may have missed.  You write

"The above is the fundamental change in the method resolution, and as such in the behaviour of NetRexx, which should be thought out. Also, it is a strong indicator for me, that Mike has thoughtfully devised this behaviour, as otherwise he would not explicitly make the reader aware of this important and fundamental property of the method resolution rules."  (My emphasis).

But on Oct 11 Kermit, in an exchange with Mike, gave an extended example expounding his point of view, and Mike replied (Oct 12):

'Nicely demonstrated -- yes that shows the issues.  Your last sentence is actually a reminder that (as I was breaking new ground) I may have been erring on the cautious side and preferring errors to be raised in 'grey areas'.   I think your proposed change is an improvement.  Now you guys just to figure out if it might break too mauch :-).

Can this mean anything other than that Mike regards changes in this area a proper subject for discussion, and at least tentatively, to view Kermit's idea favorably?

I really haven't thought about it at any depth, and I simply don't remember my original thinking -- 15 years ago, after all.  However, Rony's comment:

 

This change would remove a fundamental behaviour from NetRexx. This means among other things that *one can never be sure* from that moment on that the picked methods on a retranslate won't be totally different, as any time any superclass may qualify for such a change in behaviour. 

certainly rings a few bells and tickles some neurons.  This could well be the reason for the current behaviour. Whether that's a good thing or a bad thing is up to you guys to decide.  Certainly I don't like the idea that an addition to a superclass can break my code -- but I tend to be a bit paranoid about that sort of thing.  Perhaps consider some scenarios...

 

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[George Hovey-2]

Mike,
Thanks for the clarification.  My point is that Rony appears to feel that your own past writings make clear that the current approach is exactly what you wanted (and presumably were aware of, and sanguine about, all its implications).  I merely pointed out that your recent writings indicate the matter is at least a proper subject for discussion.  Hope I didn't get that wrong.

If so, the important thing is to thoroughly air the issues, and that is proceeding quite nicely.   Man proposes, the ARB disposes.    :)
George

On Sun, Oct 16, 2011 at 3:16 AM, Mike Cowlishaw <[hidden email]> wrote:

 

A small point you may have missed.  You write

"The above is the fundamental change in the method resolution, and as such in the behaviour of NetRexx, which should be thought out. Also, it is a strong indicator for me, that Mike has thoughtfully devised this behaviour, as otherwise he would not explicitly make the reader aware of this important and fundamental property of the method resolution rules."  (My emphasis).

But on Oct 11 Kermit, in an exchange with Mike, gave an extended example expounding his point of view, and Mike replied (Oct 12):

'Nicely demonstrated -- yes that shows the issues.  Your last sentence is actually a reminder that (as I was breaking new ground) I may have been erring on the cautious side and preferring errors to be raised in 'grey areas'.   I think your proposed change is an improvement.  Now you guys just to figure out if it might break too mauch :-).

Can this mean anything other than that Mike regards changes in this area a proper subject for discussion, and at least tentatively, to view Kermit's idea favorably?

I really haven't thought about it at any depth, and I simply don't remember my original thinking -- 15 years ago, after all.  However, Rony's comment:

 

This change would remove a fundamental behaviour from NetRexx. This means among other things that *one can never be sure* from that moment on that the picked methods on a retranslate won't be totally different, as any time any superclass may qualify for such a change in behaviour. 

certainly rings a few bells and tickles some neurons.  This could well be the reason for the current behaviour. Whether that's a good thing or a bad thing is up to you guys to decide.  Certainly I don't like the idea that an addition to a superclass can break my code -- but I tend to be a bit paranoid about that sort of thing.  Perhaps consider some scenarios...

 

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Mike Cowlishaw]

George, you got it exactly right.  Definitely a proper subject for discussion.  And I may have got it exactly right in the original design (clearly at the time I felt it was what I wanted - this was a wholly one-person design).  Or maybe I didn't get it right.  Hindsight is a wonderful thing!

 

Mike

 

Mike,
Thanks for the clarification.  My point is that Rony appears to feel that your own past writings make clear that the current approach is exactly what you wanted (and presumably were aware of, and sanguine about, all its implications).  I merely pointed out that your recent writings indicate the matter is at least a proper subject for discussion.  Hope I didn't get that wrong.

If so, the important thing is to thoroughly air the issues, and that is proceeding quite nicely.   Man proposes, the ARB disposes.    :)
George

On Sun, Oct 16, 2011 at 3:16 AM, Mike Cowlishaw <[hidden email]> wrote:

 

A small point you may have missed.  You write

"The above is the fundamental change in the method resolution, and as such in the behaviour of NetRexx, which should be thought out. Also, it is a strong indicator for me, that Mike has thoughtfully devised this behaviour, as otherwise he would not explicitly make the reader aware of this important and fundamental property of the method resolution rules."  (My emphasis).

But on Oct 11 Kermit, in an exchange with Mike, gave an extended example expounding his point of view, and Mike replied (Oct 12):

'Nicely demonstrated -- yes that shows the issues.  Your last sentence is actually a reminder that (as I was breaking new ground) I may have been erring on the cautious side and preferring errors to be raised in 'grey areas'.   I think your proposed change is an improvement.  Now you guys just to figure out if it might break too mauch :-).

Can this mean anything other than that Mike regards changes in this area a proper subject for discussion, and at least tentatively, to view Kermit's idea favorably?

I really haven't thought about it at any depth, and I simply don't remember my original thinking -- 15 years ago, after all.  However, Rony's comment:

 

This change would remove a fundamental behaviour from NetRexx. This means among other things that *one can never be sure* from that moment on that the picked methods on a retranslate won't be totally different, as any time any superclass may qualify for such a change in behaviour. 

certainly rings a few bells and tickles some neurons.  This could well be the reason for the current behaviour. Whether that's a good thing or a bad thing is up to you guys to decide.  Certainly I don't like the idea that an addition to a superclass can break my code -- but I tend to be a bit paranoid about that sort of thing.  Perhaps consider some scenarios...

 

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Kermit Kiser]

I want to thank Rony for taking the time to examine in detail the possible changes in behavior due to the proposed modifications to the NetRexx method selection algorithm. This is a "non-trivial" change in the sense of it being fundamental to NetRexx behavior and it is important to consider all of the ramifications.

I also thank those who have been testing with the new algorithm for their time and efforts. There have been no reports of problems due to the changes yet, but it is still early in that cycle and there is a lot of time to test before a new version of NetRexx could be put together. I understand that the next release of NetRexx will not happen until at least march of 2012 according to the road map on Kenai.

Also thanks to Mike for the candid admission that he does not want to be considered the final authority for these type of changes in the details of NetRexx processing! ARB?

The concerns about changing method selection so far seem focused only on the new logic that would allow NetRexx to check superclass methods when it has already found a method that it can make work by converting the argument types. Before commenting on some of the statements included in this thread below , I an going to try to summarize what we have learned so far about NetRexx behavior and proposed behavior. For the sake of this discussion, I am calling the current NetRexx behavior NR3, to include versions 1.x, 2.x, 3.00, and 3.01 of the NetRexx translator. Likewise, the newer NetRexx method selection behavior I will call NR4 for comparison purposes only. Also, I am going to assume an  inheritance chain of classes such that class X is a subclass of superclass Y which is a subclass of "supersuperclass" Z.

Imagine that a NetRexx program obtains an object "o" of type X either through inheritance or instance creation, etc., and calls a method XYZ using that object with some argument string: o.XYZ(...).  NR3 or NR4 might find that method in class X, class Y, or class Z. To completely compare behaviors, we have to consider each location separately and also whether the method selected is an "exact" match vs NetRexx performing automatic argument conversion to match it ("inexact match") since each case is handled differently. That gives us 6 basic cases to look at which should cover any more complex chains as well. Keep in mind that we are looking primarily at what happens when recompiling the NetRexx program with NR3 or NR4 even though some of these changes may affect a non-recompiled program also.

1) method XYZ is a member of class X with exact match to the calling arguments:  No changes to classes X, Y, or Z can affect method selection by NR3 or NR4 except for removing method XYZ entirely from class X, of course. Both NR3 and NR4 behave like Java in this case.

2) method XYZ is a member of class X with inexact match to the calling arguments: No changes to classes Y or Z can affect NR3 method selection, but adding a new matchable XYZ method with different signature to class X could alter the NR3 selection. Since NR4 looks at X, Y, and Z in the case of inexact matches, adding a new XYZ method to any of those classes could alter the method selected if it is a better match (lower cost).

3) method XYZ is a member of superclass Y with exact match to the calling arguments: No changes to classes Y or Z can affect the method selected by NR3 but any matchable XYZ method, exact or inexact, added to class X WILL change the method selected by NR3. Only adding an exact match XYZ method to class X can change the method selected by NR4 just as in Java.

4) method XYZ is a member of superclass Y with inexact match to the calling arguments: No change to class Z can affect the method selected by NR3 but a new XYZ method in class Y might change the selection and ANY new matchable XYZ method, exact or inexact, in class X WILL alter the method selected by NR3. Any new XYZ method in X, Y, or Z could change the method selected by NR4 but only if it is a better match.

5) method XYZ is a member of supersuperclass Z with exact match to the calling arguments: Any matchable XYZ method added to class X or superclass Y WILL change the method selected by NR3. Only an exact match XYZ method added to class X or superclass Y can change the method selected by NR4, just as in Java.

6) method XYZ is a member of supersuperclass Z with inexact match to the calling arguments: A matchable XYZ method added to supersuperclass Z could change the NR3 selection, but ANY matchable XYZ method added to class X or superclass Y WILL change the method selected by NR3 even if it is a poorer match. Any matchable XYZ method added to X, Y, or Z could change the method selected by NR4 but only if it is a better match.

The above summary shows that the proposed method selection behavior is much closer to the way that Java behaves and has less exposure to dangerous changes in method selection such as changing exact signature matches to inexact matches.  Since NetRexx uses Java to compile programs to binary code, it converts all method calls to exact matches before passing them to Java. That means that the exposure to changing methods at runtime through changes to superclasses is identical to that of Java so I don't think we need to consider it here.

I have added some comments in italics to Rony's note below.

-- Kermit


On 10/15/2011 12:48 PM, Rony G. Flatscher wrote:

Kermit,

sorry for the late (and brief) answers/comments, have been in a sort of "land under water" mode, which will last a while, I am afraid.

On 13.10.2011 22:51, Kermit Kiser wrote:

I have modified the hijacked title as it was getting a little long, etc.

I am not sure I can totally separate my response by versions, as some of my comments here directly bear on conclusions in part 2.

First, please forgive me if this background is old news to you, but at the Java 1.5 level, Sun began to convert some library modules to replace "String" parameters with "CharSequence" parameters and add "appendable" interfaces to them. This significantly modified the IO classes such as Writers and Streams. It did not cause any problems for Java programs because Java has very strict algorithms for method selection and inheritance.

Well, whatever changes Sun/Oracle adds to Java, they always try to remain backwardly compatible. Hence I would be interested to learn about changes in the IO classes that yielded incompatibilities with Java programs.

Unfortunately it severely negatively impacted NetRexx programs which can no longer extend those classes nor access the new append methods and cannot even easily access the common "write(String)" methods because the special case "write(int)" methods make them invisible as reported here recently in this thread by Alan and KP.

The "Alan-issue" is not an issue/bug of NetRexx IMHO, as NetRexx behaves according to its specifications: it picks a matching method in the current class.

The current NetRexx specifications are not Java compatible. A Java programmer requesting a write(String) method would get that method, not a probably incompatible write(int) method.

These are the problems that I have tried to address with my proposed changes to NetRexx method resolution. I  don't know about anyone else but I don't appreciate being told that we are not having real problems.

Here is a test program which does simple stuff that any Java programmer can do with no problem and the output you get if you try to compile it with NetRexx 3.01:
---------------------------------------------------------
mystream=BufferedWriter(StringWriter())

mystream.write("something")

The above is the "Alan-issue": 

• casting to the superclass allows NetRexx to regard the superclass as the "current class" and hence is allowed to pick a matching method there (or one of its superclasses), like:
     (Writer mystream).write("something")

mystream.append("something")

This is a type mismatch as the type "something" is not of type CharSequence, casting the argument resolves this error message, like:
   mystream.append(CharSequence "something")

class newstream extends PrintStream
    method newstream
        super("somefile")
----------------------------------------------------------
Program charseqtests3.nrx
[C:\NetRexx\testing\charseqtests3.nrx 3 1 8] Error: Cannot convert constant value 'something' to type 'int'

Correct, BufferedWriter defines a method 'write(int)', but not a method 'write(String)', which is defined in its superclass Writer.

It would sure be nice if this stuff just worked correctly like it does in Java without needing all of those special casts!

[C:\NetRexx\testing\charseqtests3.nrx 4 10 6] Error: More than one method matches the name and signature 'java.io.Writer.append(java.lang.String)'

The error message in this case is misleading as there is no method: 'java.io.Writer.append(java.lang.String)' , instead there are 'java.io.Writer.append(char)' or 'java.io.Writer.append(CharSequence)' which NetRexx thinks are candidates. [Wondering a little bit why NetRexx would consider the interface type CharSequence to be equivalent to java.lang.String, which merely implements that very same interface.)

---- ---- ----

 
  === class newstream ===
    constructor newstream()
      signals FileNotFoundException
[C:\NetRexx\testing\charseqtests3.nrx 6 7 9] Error: Class is not abstract, yet it does not implement method 'append(CharSequence) returns java.lang.Appendable' from abstract class 'java.lang.Appendable'
[C:\NetRexx\testing\charseqtests3.nrx 6 7 9] Error: Class is not abstract, yet it does not implement method 'append(CharSequence,int,int) returns java.lang.Appendable' from abstract class 'java.lang.Appendable'
[C:\NetRexx\testing\charseqtests3.nrx 6 7 9] Error: Class is not abstract, yet it does not implement method 'append(char) returns java.lang.Appendable' from abstract class 'java.lang.Appendable'
Compilation of 'charseqtests3.nrx' failed [2 classes, 5 errors]
 -----------------------------------------------------------------------------------------------

These error messages seem to be wrong and indicate that there is somewhere a problem in the current NetRexx algorithms resolving constructor method demands, as the superclass is concrete and implements all of the interfaces, such that the extending class has no need to implement them.  So the current NetRexx should not issue these error messages and a bug report is in place.

However, this does not mandate that the method resolution rules of the current NetRexx needs to be totally changed, introducing a totally different behaviour, and one, that cannot be predicted by NetRexx programmers.

The experimental "after3.01" NetRexx translator with enhanced method selection compiles the above program correctly and it runs without error.

BTW:  The method selection algorithm overview listed by Rony is not precisely correct as it omits the scan of interface classes during the recursive superclass scan and the "unknown" calculation that is performed to decide if a method is selected or an "ambiguous" message is issued.

 If I understand the idea of the scenario proposed by Rony, each class is maintained by a different developer without collaboration. But there seems to be a missing test case at stage 3 - Suppose that not the developer of SuperSuperguy but the developer of Superguy adds the new String handling method? :

method process(val=String)
         say this".process(val=String):" "val="val "val.substr(0,2)="val.substring(0,2)

Here is the output of the mr.nrx program after compiling with the 3.01 translator:
-----------------------------------------------------------------------
enter a value to be processed:
17
[hidden email](val=String): val=17 val.substr(0,2)=17
Java method mr.nrx / NetRexx 3.00 11 Jun 2011
------------------------------------------------------------------------

Wait! You mean the "stable" current NetRexx translator changed the method called when the superclass programmer changed his class? Yep, because NetRexx is not Java and when you allow NetRexx to convert arguments and select methods for you, that selection can be changed by the actions of a superclass programmer!

Right! You pinpoint to the following observation: the method NetRexx picks needs not to be the one the programmer expects to be picked. The assumption, that the cost based method picking always is identical to the method the NetRexx programmer's *thinks* that gets picked, is not necessarily the same.

What happens is a "method-picking guessing" by the translator using some cost-based algorithm, which ensures reproducibllity of method picking. It does not (and cannot) assure/assert, that NetRexx will always pick the method the NetRexx programmer wishes to be picked. For that reason it is always necessary, that NetRexx programmers are aware of this, such that they can explicitly cast arguments to methods where the casts narrow the pickable method down to the one the NetRexx programmer wishes to be picked.

This is BTW true for the experimental NetRexx as well.

---rony

P.S.: W.r.t. to the CharSequence interface: it would be a meaningful enhancement to extend the NetRexx conversion rules to cover CharSequence explicitly as well. Probably its costs should be different to String conversions to not get have the same minimum costs as the String-argument versions (which would lead to an error message of NetRexx to have the NetRexx programmer decide which method it should pick).

Actually the String<=>CharSequence<=>Rexx conversions were added to NetRexx 3.01 although the cost setting of 17 is the same as Rexx<=>String. That cost setting can be revisited if it causes method selection problems, however NetRexx 3.00 produces the same error messages so I don't think those conversion costs are relevant here.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Kermit Kiser]

Comments in italics.

-- Kermit

On 10/15/2011 12:48 PM, Rony G. Flatscher wrote:

On 13.10.2011 22:59, Kermit Kiser wrote:

Hi all -

Here are some more thoughts on hijacking:

For reasons of documentation versioning issues no doc changes have been made yet, but I did describe the NetRexx method selection algorithms on the list a few days ago. Here is an updated summary (overview) of those algorithms showing the differences:

The current (3.01) method selection logic is a recursive algorithm:

1) If any methods in the current class can be used, select the best fit (least cost algorithm created by Mike) and use it.
2) If any methods in the superclass can be used, select the best fit using this algorithm and use it.
3) If any methods in interfaces can be used, select the best fit (least cost) and use it.

The proposed (after 3.01) method selection logic is the following recursive algorithm:

1) If there is an exact match in the current class, use it.
2) If any methods in the current class can be used, save the best fit and it's cost.
3) If there is an exact match in the superclass, use it.
4) If any superclass methods can be used, save the best fit using this algorithm and it's cost.
5) If any interface methods can be used, save the best fit and it's cost.
6) Select the best fit (least cost) of the saved methods and use it. Ties go to the first method found in the inheritance tree just as in Java.

Some more details: If two methods with the same cost are found at any level, an ambiguous message is issued in either algorithm above. The cost calculation used in the proposed algorithm is the same 15 year old calculation as used in the current algorithm with one minor exception: If a tested method is an interface method, either 1 or 2 points are added to the calculated cost. This prevents a cost conflict between an interface method and it's concrete implementation which otherwise would have the exact same signature and cost. (There are two separate add values because the interface methods are checked twice.)

I will try a rewrite of the much more detailed algorithm described in the language manual when there is time. Meanwhile it should be clear that the following note from that manual is NOT true with the proposed selection algorithm:

"Note: When a method is found in a class, superclasses of that class are not searched for methods, even though a lower-cost method may exist in a superclass."

The above is the fundamental change in the method resolution, and as such in the behaviour of NetRexx, which should be thought out. Also, it is a strong indicator for me, that Mike has thoughtfully devised this behaviour, as otherwise he would not explicitly make the reader aware of this important and fundamental property of the method resolution rules.

There seem to be some copy/paste errors in the scenarios listed below, so I won't say anything more except to reiterate that even the current translators can pick a different method on a recompile if the external classes have changed and I believe the new algorithm is less fragile (more stable and robust) than the old one.

There is an important distinction here: if this happens, it only can happen in the *current class*, if the alternate methods have different costs.

See summary in my response to Part 1 for a more complete explanation of what can happen.

This change would remove a fundamental behaviour from NetRexx. This means among other things that *one can never be sure* from that moment on that the picked methods on a retranslate won't be totally different, as any time any superclass may qualify for such a change in behaviour.

---rony

As I showed in the response to Part 1, the modified behavior of the proposed method selection algorithm is much more compatible with Java and any changes in methods selected are far less likely to be dangerous than the unanticipated method changes possible in the current NetRexx version.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[ThSITC]

I would like to *fully support* Kermit with his proposed changes.

Exact matches in SuperClasses *have to* over-rule any costing algorithms.
Thomas Schneider.
==========================================================
Am 17.10.2011 01:14, schrieb Kermit Kiser:

Comments in italics.

-- Kermit

On 10/15/2011 12:48 PM, Rony G. Flatscher wrote:

On 13.10.2011 22:59, Kermit Kiser wrote:

Hi all -

Here are some more thoughts on hijacking:

For reasons of documentation versioning issues no doc changes have been made yet, but I did describe the NetRexx method selection algorithms on the list a few days ago. Here is an updated summary (overview) of those algorithms showing the differences:

The current (3.01) method selection logic is a recursive algorithm:

1) If any methods in the current class can be used, select the best fit (least cost algorithm created by Mike) and use it.
2) If any methods in the superclass can be used, select the best fit using this algorithm and use it.
3) If any methods in interfaces can be used, select the best fit (least cost) and use it.

The proposed (after 3.01) method selection logic is the following recursive algorithm:

1) If there is an exact match in the current class, use it.
2) If any methods in the current class can be used, save the best fit and it's cost.
3) If there is an exact match in the superclass, use it.
4) If any superclass methods can be used, save the best fit using this algorithm and it's cost.
5) If any interface methods can be used, save the best fit and it's cost.
6) Select the best fit (least cost) of the saved methods and use it. Ties go to the first method found in the inheritance tree just as in Java.

Some more details: If two methods with the same cost are found at any level, an ambiguous message is issued in either algorithm above. The cost calculation used in the proposed algorithm is the same 15 year old calculation as used in the current algorithm with one minor exception: If a tested method is an interface method, either 1 or 2 points are added to the calculated cost. This prevents a cost conflict between an interface method and it's concrete implementation which otherwise would have the exact same signature and cost. (There are two separate add values because the interface methods are checked twice.)

I will try a rewrite of the much more detailed algorithm described in the language manual when there is time. Meanwhile it should be clear that the following note from that manual is NOT true with the proposed selection algorithm:

"Note: When a method is found in a class, superclasses of that class are not searched for methods, even though a lower-cost method may exist in a superclass."

The above is the fundamental change in the method resolution, and as such in the behaviour of NetRexx, which should be thought out. Also, it is a strong indicator for me, that Mike has thoughtfully devised this behaviour, as otherwise he would not explicitly make the reader aware of this important and fundamental property of the method resolution rules.

There seem to be some copy/paste errors in the scenarios listed below, so I won't say anything more except to reiterate that even the current translators can pick a different method on a recompile if the external classes have changed and I believe the new algorithm is less fragile (more stable and robust) than the old one.

There is an important distinction here: if this happens, it only can happen in the *current class*, if the alternate methods have different costs.

See summary in my response to Part 1 for a more complete explanation of what can happen.

This change would remove a fundamental behaviour from NetRexx. This means among other things that *one can never be sure* from that moment on that the picked methods on a retranslate won't be totally different, as any time any superclass may qualify for such a change in behaviour.

---rony

As I showed in the response to Part 1, the modified behavior of the proposed method selection algorithm is much more compatible with Java and any changes in methods selected are far less likely to be dangerous than the unanticipated method changes possible in the current NetRexx version.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[rvjansen]

> details of NetRexx processing! ARB?

Definitely ARB. I'll schedule it for the next meeting, when we need to
officially release 3.01 so we can focus on .next.

Thanks to all for these interesting discussions - and Kermit for
implementing these changes so that the discussions will not be purly
academical.

best regards,

René Jansen

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Rony G. Flatscher (wu-wien)]

Hi Kermit,

just a few (almost last :) ) remarks:

On 17.10.2011 01:13, Kermit Kiser wrote:

... cut ...

Imagine that a NetRexx program obtains an object "o" of type X either through inheritance or instance creation, etc., and calls a method XYZ using that object with some argument string: o.XYZ(...).  NR3 or NR4 might find that method in class X, class Y, or class Z.

Search for a matching method always starts at the class from which the object got created from. If a matching method can be found there, then superclasses are not searched for anymore.

To completely compare behaviors, we have to consider each location separately and also whether the method selected is an "exact" match vs NetRexx performing automatic argument conversion to match it ("inexact match") since each case is handled differently.

Currently, if a method can be found in the class of which an object is an instance from, then that method is used, irrespectably whether matching methods can be found in superclasses.

That gives us 6 basic cases to look at which should cover any more complex chains as well. Keep in mind that we are looking primarily at what happens when recompiling the NetRexx program with NR3 or NR4 even though some of these changes may affect a non-recompiled program also.

1) method XYZ is a member of class X with exact match to the calling arguments:  No changes to classes X, Y, or Z can affect method selection by NR3 or NR4 except for removing method XYZ entirely from class X, of course. Both NR3 and NR4 behave like Java in this case.

2) method XYZ is a member of class X with inexact match to the calling arguments: No changes to classes Y or Z can affect NR3 method selection, but adding a new matchable XYZ method with different signature to class X could alter the NR3 selection. Since NR4 looks at X, Y, and Z in the case of inexact matches, adding a new XYZ method to any of those classes could alter the method selected if it is a better match (lower cost).

Ad "better match (lower cost)": this is one of the basic assumptions that I have been trying to challenge.

It cannot be said whether a method with lower costs in superclasses is a "better match" as a found method in the class the object got created from! This assumption can only turn true, if the expectations of the NetRexx programmer *by coincidence* meet exactly the assumptions underlying the cost-based method-picking algorithm. As no one knows the cost-based algorithm or is aware of the costs, an exact match of the NetRexx programmer expectation with the NetRexx method picking cost-algorithms is pure luck.
:)

There is another interesting point here IMHO: in Alan's example, everyone who reads the code is inclined to conclude, that indeed the method in the superclass (expecting a String) is better than the one in the class the object got created from (expecting an int). The reason probably being that the program's Rexx variable, which serves as an argument, does not contain a number. So the conclusion is even stronger: it is only the String-version of the method that in this very particular case is the right method to pick!

As NetRexx has to guess at translation/compile time which method is "best", its assumptions are of paramount importance. Consider Alan's example and his Rexx value having an integer value like "17", which could be a String, but it could also be expected to be used as a number, perfectly fitting a conversion to int!

So, if the NR4-behaviour picks Alan's "correct method", then this happens by pure luck only! Had Alan's example Rexx variable contained the string "17", then it would  not be clear, that picking the supercalss method would be the "correct" method to be picked. And actually, if Alan intended to use the int-version with that Rexx value "17", then picking the superclass' String method would be an error with NR4!

@Java: Java is very different here (and cannot be compared to NetRexx) as in Java the datatypes are strictly given, and the Java compiler will always pick an exactly matching method. This is also the reason why constant casting is so important (and cumbersome sometimes) in Java programs. (Or: NetRexx ain't Java! The NetRexx cost algorithm is a surrogate which asserts that NetRexx will always pick the same method, because all of the conversion costs are known, short of having a better alternative for picking a method.)

... cut ...

The above summary shows that the proposed method selection behavior is much closer to the way that Java behaves

The warning here: this is purely by co-incidence and can be even wrong (like in the case, where "17" was indeed meant to be an integer number by the programmer in Alan's example).

and has less exposure to dangerous changes in method selection such as changing exact signature matches to inexact matches. 

There is a trap here, I think: taking a Rexx value to be always a String value.

If "options binary strictassign" was in effect, then these arguments may be understandable, but not if Rexx values serve as wildcards for the primitive types (and their wrapper classes) and String (and CharSequence for that matter).

Since NetRexx uses Java to compile programs to binary code, it converts all method calls to exact matches before passing them to Java.

Well, NetRexx *translates* NetRexx code to Java code, which then is compiled with a Java compiler.

The ongoing discussion is about how the NetRexx code should translate to Java code.

That means that the exposure to changing methods at runtime through changes to superclasses is identical to that of Java so I don't think we need to consider it here.

Could you explain this a little bit more?

I have added some comments in italics to Rony's note below.

... cut ...

The "Alan-issue" is not an issue/bug of NetRexx IMHO, as NetRexx behaves according to its specifications: it picks a matching method in the current class.

The current NetRexx specifications are not Java compatible. A Java programmer requesting a write(String) method would get that method, not a probably incompatible write(int) method.

But the NetRexx programmer did not request the "write(String)" method, he requested a "write(Rexx)" method!

Therefore the current NetRexx translation, finding a "write(int)" method picked that method, as it is known that a Rexx datatype can be converted to an int, so this is a safe conversion. If at runtime the Rexx value does not allow for translating to an int, a runtime error is thrown (which is the case in Alan's example).

Correct, BufferedWriter defines a method 'write(int)', but not a method 'write(String)', which is defined in its superclass Writer.

It would sure be nice if this stuff just worked correctly like it does in Java without needing all of those special casts!

Yes, I agree, that it would be nice. But this is a sort of asking for a(n impossible) "squared circle".

P.S.: W.r.t. to the CharSequence interface: it would be a meaningful enhancement to extend the NetRexx conversion rules to cover CharSequence explicitly as well. Probably its costs should be different to String conversions to not get have the same minimum costs as the String-argument versions (which would lead to an error message of NetRexx to have the NetRexx programmer decide which method it should pick).

Actually the String<=>CharSequence<=>Rexx conversions were added to NetRexx 3.01 although the cost setting of 17 is the same as Rexx<=>String. That cost setting can be revisited if it causes method selection problems, however NetRexx 3.00 produces the same error messages so I don't think those conversion costs are relevant here.

Ah, very interesting!

Please allow me a few questions then:

• Are there then the constructors Rexx(CharSequence) and Rexx(CharSequence[]) available as well?
• Ad weight/cost being the same between converting Rexx to String and CharSequence: that would be o.k. (as would be different costs, as long as they are close and just being used to favor one method version over the other, i.e. biasing a String over CharSequence or vice versa), however, it would be interesting to learn the reasons for the same weights/costs in order to make them available to discussion.

A last remark: probably all has been said, discussed in the context of the original problem Alan put forward, and the information that was given since then (including CharSequence and an erorneous behaviour w.r.t. constructors if extending a concrete class that implements interfaces, which methods are reported to be missing in the implementation of the extended class). With this e-mail I hope to have pin-pointed at (sometimes maybe hidden) assumptions, that might be challengable (which does not mean, that the assumptions are bad, just that they have not been explicitly discussed in this context and in the necessary depth, at least IMHO) and may not have been that clear from the conversation so far.

---rony


_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[alansam]

Rony,

At this point I take issue with you.  

 

But the NetRexx programmer did not request the "write(String)" method, he requested a "write(Rexx)" method!

I did indeed (via casting) request "write(String)" but the current NetRexx implementation silently ignored that demand and internally coerced my String back to a Rexx then invoked write(int).  In my opinion this is more of a surprise than the results given by the change suggested by Kermit.

Original attempt:

filebuff.write(String rec)

eventual resolution:

(Writer filebuff).write(rec)

If I know (by reading the documentation of the class I'm using) that a method in the class hierarchy exists which matches 100% what I want then it is a surprise to find that the compiler/translator jumps through hoops to use something else regardless of how much I insist via casting.  This is particularly egregious as it only shows up as a runtime error so may not be caught in testing and make its way out onto a customer's system.

Alan.

--
Can't tweet, won't tweet!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/