Unknown Method in SOME STVs?

[tmiranda]

Sean, Plucky,

Thanks to both of you. I've been getting a little more comfortable with the Sun java docs but as always when learning something new the first few steps take a while.

I am getting ready to delve into java programming.

I'll try the _parseInt method to solve this particular problem. Plucky, If you do get around to making your methods accept integers I'd appreciate the jar.

Tom

[GKusnick]

Originally Posted by stuckless

Depending on your java version you could still end up with a method not found.

But again, if we're talking about Studio code, the method lookup is done by Sage using Sage rules, not by Java using Java rules.

Originally Posted by stuckless

In phoenix, I will sometimes create the method signatures that accept an Object, then I determine the type inside the method. This is not ideal programming behaviour, but it saves me from creating a bunch of overloaded methods for each type, int, long, float, string, etc.

In the case of int, long, float, and double, automatic widening applies so one method can cover them all (unless you specifically want to distinguish those cases in order to implement different behaviors).

Plus there are other reasons besides clarity to prefer overloads to generic Object methods. In general you want the compiler to do as much type checking and method resolution as possible, both to avoid runtime overhead and to catch type errors as early as possible. Pass the wrong type to an overloaded method and you find out right away. Pass the wrong type to a method that takes Object and you might not find out until after your code ships.

[tmiranda]

Plucky,

I have my STV working using your current api's and the conversion methods you all pointed out to me. No need to create any special api's for integers (unless you need them for something else.) Please put all of your efforts into Ortus and SMM

Tom

[PLUCKYHD]

Originally Posted by tmiranda

Plucky,

I have my STV working using your current api's and the conversion methods you all pointed out to me. No need to create any special api's for integers (unless you need them for something else.) Please put all of your efforts into Ortus and SMM

Tom

Tom,

Glad to hear I did send you a new jar last night If you want to use it.

[stuckless]

Originally Posted by GKusnick

But again, if we're talking about Studio code, the method lookup is done by Sage using Sage rules, not by Java using Java rules.



In the case of int, long, float, and double, automatic widening applies so one method can cover them all (unless you specifically want to distinguish those cases in order to implement different behaviors).

Plus there are other reasons besides clarity to prefer overloads to generic Object methods. In general you want the compiler to do as much type checking and method resolution as possible, both to avoid runtime overhead and to catch type errors as early as possible. Pass the wrong type to an overloaded method and you find out right away. Pass the wrong type to a method that takes Object and you might not find out until after your code ships.

I can't really disagree with anything... and no one appreciates the importance of the compiler doing the work more than I... (I especially love the addition of generics in java5).

My point was really about simplify the consumability of the api. While, I would never encourage writing method signatures that accept an object in normal java practice... it can be quite useful when dealing with the STV, and core sage does it as well

By manually handling the type conversion, you can also provide better messages back to the user, which could improve the usability of the api, while adding in some overhead. ie, if my method accepts an Object but requires an int, then I can inform the user that they passed an invalid parameter type, and even dump the type in the message... as apposed to "unknown method", which even to a seasoned developer, you are left wondering if it's a typo in the method name or a signature issue.

I find that writing APIs that are consumed by the stv, my approach changes. Users of the STV do not have benefit of the ide telling them that they are misspelled a method, or missing an arg, etc. To ensure the best of both worlds... I tend to write very specific typesafe apis (using generics and overloading, etc), but then I create an "API" that is published and meant to be directly consumed by the STV developers. Because I'm lazy, I also, tend to auto-generate those STV facing apis, and in some cases, using annotations, I allow for "Object" parameters that are manually converted to a specific type, for no other reason as to make it easier on the STV developers to use the API. The other advantage of this layered approach, is that I can also refactor the underlying apis while having minimal impact on the STV.