Error message resulting from scope problem

[Stephen Rondeau]

I was converting a Java Swing program from a web tutorial and ran into this error:

 205 +++               actionLabel.setText(prefix||String(source.getPassword()) || "\"")
     +++                                                         ^^^^^^^^^^^
     +++ Error: The method 'getPassword()' cannot be found in class 'javax.swing.JTextField' or a superclass

After some headscratching, I determined that it was a scope problem, since "source" was define/used as JTextField prior to this use as a JPasswordField:

        if (textFieldString.equals(e.getActionCommand()))
          then do
            source = JTextField e.getSource()
            actionLabel.setText(prefix || source.getText()"\"")
          end
          else if (passwordFieldString.equals(e.getActionCommand()))
            then do
              source = JPasswordField e.getSource()
              actionLabel.setText(prefix||String(source.getPassword()) || "\"")
            end

To fix it, I used a different variable name for "source" for the JPassword use.

I was wondering if there is any way the compiler can catch this as a scope error, so the resulting message can be less misleading as to the nature of the problem.

[Peter Sharp-2]

Most compilers I've used do/provide this with a crossref/xref option. Is this not available in NetRexx?

Peter

On 23 Dec 2013 05:56, "Stephen Rondeau" <[hidden email]> wrote:
>
>...
> I was wondering if there is any way the compiler can catch this as a scope
> error, so the resulting message can be less misleading as to the nature of
> the problem

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

[Mike Cowlishaw]

 

Most compilers I've used do/provide this with a crossref/xref option. Is this not available in NetRexx?

Yes, NetRexx provides a crossref option (unlike most 'modern' compilers).  But I suspect that would not have helped in this case because the re-use of the 'source' variable was valid because the second type used was a subclass of the first use.  [I have not looked at the classes in question.]

In short .. the compiler is doing exactly as it is supposed to, and if the method used belonged to the higher class then it would have worked.  As it did not, it reported that the method could not be found in JTextField, which is correct and also indicates the type of the variable 'source' correctly (as would also be shown in the crossref), I think.

One could definitely argue that dynamic typing would be more Rexx-like in this case, but there's also a strong argument that following Java rules is appropriate here, too.    A 'pitfall' of inheritance, really.

Mike

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