May I repeat MY BET

[Kermit Kiser]

Hi David ;

My code is nobinary. The error messages I was getting without the explicit conversion from Rexx to String looked something like this:

 +++ Error: The method 'setTextViewText(int,netrexx.lang.Rexx)' cannot be found in class 'android.widget.RemoteViews' or a superclass

Apparently NetRexx does not realize that a string conversion is needed sometimes. The way I did the conversion was probably not the best (a cast works too: String (expression) where expression is a Rexx type.) , but when I looked at the code later, it made it instantly clear to me what was being done and why.

It sounds like you encountered a similar problem to mine.

-- Kermit


David Requena wrote:

Kermit,

El 13/04/2010 20:19, Kermit Kiser escribió:

(TextView findViewById(R.id.date_display)).setText(Rexx(datepick.getYear"/"datepick.getMonth+1"/"datepick.getDayOfMonth).toString)

been having a closer look at this code snippet (will focus on the red section).

First, I dont really understand why are you explicitly instantiating a Rexx object.

My be I'm being dumb but as I see it there're are two posibilities here:

- options binary is in effect: the abbuted String objects become an String which needs no further conversion
- options nobinary in effect: abbuted Strings become a Rexx object whithout further need for explicit instantiation

what I'm I missing?

where the setText method of a TextView requires a CharSequence rather than a String which NetRexx would recognize and automatically convert for.

I was kinda hoping that we could update open source NetRexx to handle those conversions automatically. What do you think?

I agree NetRexx type conversion has a major shortcoming in its present form. Namely, type lookups take into account
any ancestor classes but not implemented interfaces. In the case at hand, it would be reasonable to expect Rexx type
objects be automatically converted to String whether a String object or 'an object implementing any of String implemented
interfaces' is expected.

Another 'type lookup' issue related to interfaces I was once bitten by is as follows:

- have two overloaded methods someMethod(someArg=Object) and someMethod(someArg=SomeInerface)
- have an object someObject of class SomeClass implements SomeInterface
- have a call to someMethod(someObject)

NetRexxC is unable to resolve which method it is to call so you get an error. Again seems that implemented interfaces
are not taken into account when resolving types (well, they're but with a same priority than inheritance...)

sou you're forced to explicitly cast as in someMethod(SomeInterface someObject)

I would say that NetRexx would benefit from mirroring java's behaviour more closely here

On the compiler speed issue I have mixed feelings. The largest module in my current project is about 2000 lines of NetRexx (not many are comments). A project build takes from 10 to 20 seconds depending on various factors like what else is running on the system (3 and 1/2 year old dual core 2 GHz Turion). Granted that only part of that time is from the NetRexx compiles, I would love to not have to wait so long before I can download the completed build to a phone and test some trivial change (which I have to do frequently). Because of that wait and other concerns I am contemplating upgrading to a current top line quad core i7 system to improve compile times. Better compiler efficiency would be great but not if it increases programming complexity. Does that make sense?

I'll vote for a faster compiler any moment as long as the goal does not imply modifying the language. REXX family languages
always intended to be languages making life easy for programmers, not for language implementors. Going 'the go route' could
in fact yield a very fast compiler. One that I probably won't be using if I'm being forced to do inside my head a host of the
tasks the compiler should be doing :-)

I would propose, lets concentrate on having the best language ever. Then we try to make the best/fastest possible compiler for it.
Sacrificing language terseness in exchange for compiler efficiency sounds weird to me in the REXX world.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

  

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[David Requena]

Kermit,

I was making two distinct observations on your snippet. Sorry if I didn't make it clear.

El 15/04/2010 20:32, Kermit Kiser escribió:

My code is nobinary.

So 'Rexx >= (String("foo")String("bar"))' evaluates to 1 (true); no need for 'Rexx(String("foo")String("bar"))' as the expression is already of type Rexx.

This is of course non related to the type conversion issue at hand.

The error messages I was getting without the explicit conversion from Rexx to String looked something like this:

 +++ Error: The method 'setTextViewText(int,netrexx.lang.Rexx)' cannot be found in class 'android.widget.RemoteViews' or a superclass

Yeah, this is the error I would expect. As it appears, current rule for auto conversion from Rexx to String is:

"Convert Rexx to String whenever a String object is required"

What I propose is to change this rule to:

"Convert Rexx to String whenever an object is required which either:
a) is of class String
b) implements any of the String implemented interfaces (Serializable, Comparable, CharSequence)
"

Note the 'b)' option might be furthered with 'when not already implemented by the Rexx type'. This would cater to Serializable.

That way, given a method signature 'void setText(CharSequence arg)', a Rexx object would be converted to String; being
CharSequence an interface implemented by String. This should be a safe conversion under any circumstances.

Apparently NetRexx does not realize that a string conversion is needed sometimes. The way I did the conversion was probably not the best (a cast works too: String (expression) where expression is a Rexx type.) , but when I looked at the code later, it made it instantly clear to me what was being done and why.

That's in my view a matter of taste. No comment at my end :-)

It sounds like you encountered a similar problem to mine.

hmm.. I don't think so, not really. It's just related to the same area of type inference/lookup/conversion of the language.
That is IMHO the NetRexx general area which would most benefit from a little overhaul.


_______________________________________________
Ibm-netrexx mailing list
[hidden email]