I think interfaces should NOT be using primitive types. We should always use the Object form of the primitive.
For example :
In
instead of this :
enablePin(int address);
do this :
enablePin(Integer address);
In the past I thought int was somehow more effecient or cleaner than using the Object form, but in MRL-Land that is not the case. In fact it can cause problems.
In MRL-Land messages are sent to call other methods, when this is done the parameters are wrapped up in an Object array. So primitives will always arrive at a method as Objects. This is often referred to as "boxing" - and is the result of MRL's messaging.
When the message arrives at its destination, and tries to invoke the method .. it will "miss" enablePin(int address) because its carrying an Integer :(
Our message will make another try and do an efficient search of methods. In this case it will find a cached method which matches the method name "enablePin" but its been overloaded with a String !
enablePin(String pinName)
BOOM - NoWorky !
But if I change it to enablePin(Integer address);
... goodtimes ...
primitives vs objects
Hey Grog,
Interesting issue you've discovered there. There are some subtle differences by passing a primitive vs an object. First and biggest one that jumps out to me is that an Object can be null, a primitive can not. Second, there's a slightly larger memory overhead for an object vs a primitive, but this is likely neligable in the grand scheme of all memory being used.
So, I'm ok if we stop passing primitives, but it does worry me that we'll start seeing a lot of null pointer exceptions in odd places potentially.
It seems like a nasty bug you've found in the method cache (perhaps I'm partly responsible for that...) So, rather than changing all our interfaces/method signatures to take objects vs primitives, how difficult would it be to work around this in the method cache?!
Curious... I thought caching
Curious... I thought caching keys we're crudely done with parameter ordinals - but they have type names ..
I'm guessing overloading doesn't pan out well although I haven't followed on the logic..
a good litmus test is
enablePin(String name) & enablePin(int x) .. this consistently fails for me .
If I remembered correctly (don't count on it) - enablePin(int) failed immediately even without using enablePin(String) .. if it was invoked or done through a send("enablePin" 7)
I'd be into exploring this deeper to avoid Draconion mandates .. but even if we do figure it out - there will be always an first call fail with primitives I don't see a way around ..