Servoy 6.0 alpha 5

[rossent]

Although Johan!

I see that if I do firstShow instanceof Boolean (for a default Servoy onShow method) I get true, and if I do typeof(firstShow) I get boolean. I honestly don't know how you did that because they are not synonymous in JavaScript and that can't be replicated in scripting. I'm not sure how I can have instanceof Boolean be true and get typeof boolean??

If I try to replicate that I can't...

Code: Select all

function test() {
   var x = new Boolean(1);
   application.output(typeof(x));
   application.output(x instanceof Boolean);
}


I get object from typeof
and I get true from instanceof
(which is what I would expect)

Somehow your firstShow parameter is both Boolean and boolean!

it is just a normal boolean

Code: Select all

function test() {
   var x = true;
   application.output(typeof(x));
   application.output(x instanceof Boolean);
}


When you use "instanceof" with the primitive datatypes, you get the automatic wrapper object for them. Set x to 1 and you will "find" that it is both a number and Number, or set it to 's' and it will be string and String....

[jcompagner]

yes i think that typeof is just strange...
dont know why you would really us that
instanceof seems to be way more specific gives you way more output the for many things then just 'object'

js does know Date as a object type and everything is just Object

thats why when you create:

var x = true

and you give that to a function

you can use.

@param {Boolean}
@param {boolean}
@param {Object}
@param {object}

all 4 are fine to use

[jbader]

When you use "instanceof" with the primitive datatypes, you get the automatic wrapper object for them

I do not see that, and have never heard of that. Do you see something different?

Code: Select all

js> 'test' instanceof String
false
js> 4 instanceof Number
false
js> false instanceof Boolean
false
js>

[jbader]

yes i think that typeof is just strange...
dont know why you would really us that

typeof is necessary to discover datatypes.

instanceof seems to be way more specific gives you way more output the for many things then just 'object'

instanceof won't work on primitives at all (and does not discover datatypes). Its syntax requires a Class' constructor name as the right hand operand and there is no constructor for the primitives. The proof to this is below...

Code: Select all

false instanceof boolean

will throw an exception (unsupported operand really)!

So instanceof is there to tell you if a particular object is an instance of a particular class, and that isn't synonymous with datatype in JS.

js does know Date as a object type and everything is just Object

It knows Date as an object yes, but not as a datatype. there is no Date/date datatype in JS.

thats why when you create:

var x = true

and you give that to a function

you can use.

@param {Boolean}
@param {boolean}
@param {Object}
@param {object}

all 4 are fine to use

Actually in that particular example true is primitive and is not Boolean, nor is it Object, nor even object. It is only primitive / boolean. So the docblock would only be accurate if it ready @param {boolean}

I mentioned before that I wasn't really suggesting that anything was wrong with the Servoy implementation, but I think I am changing my mind b/c now that I see that somehow there are parameters being passed around that are somehow both (for example) Boolean and boolean, I believe that something is arye. Perhaps there is some inproper casting happening somewhere or an accessor has been overwritten? I don't know how something can be both boolean and Boolean. Meaning it shouldn't be possible for something to be an instance of Boolean and be primitive.

REMINDER: I'm only brining this up b/c of the following reported fix.

[fix] 360543 DLTK: no warning generated for functions that don't return what the JSDoc specifies or vise versa

And I am thinking that if the editor is going to warn me about an improper return value, which does not match @returns it would be most useful if it caught differences between primitives and objects. Otherwise I suppose it is really only catching returning a string when you show @returns {Boolean} etc, and while that is really helpful, it's easier to spot that on your own, whereas sometimes it's harder to spot the other cases.

[rossent]

When you use "instanceof" with the primitive datatypes, you get the automatic wrapper object for them

I do not see that, and have never heard of that. Do you see something different?

Code: Select all

js> 'test' instanceof String
false
js> 4 instanceof Number
false
js> false instanceof Boolean
false
js>

I am not sure how you got your results, but they really are not the right thing expected. See the attachment from the interactive console.
Regarding the transient wrapper objects for the primitive datatypes in JavaScript - the best explanation which I have seen is in the book "JavaScript: The definitive Guide" by David Flanagan - there is a whole chapter on them.

[jbader]

When you use "instanceof" with the primitive datatypes, you get the automatic wrapper object for them

I do not see that, and have never heard of that. Do you see something different?

Code: Select all

js> 'test' instanceof String
false
js> 4 instanceof Number
false
js> false instanceof Boolean
false
js>

I am not sure how you got your results, but they really are not the right thing expected. See the attachment from the interactive console.
Regarding the transient wrapper objects for the primitive datatypes in JavaScript - the best explanation which I have seen is in the book "JavaScript: The definitive Guide" by David Flanagan - there is a whole chapter on them.

Transient wrapper objects occur when you treat a primitive like an object. e.g. if you call .length() on a primitive string. What happens in those cases is a new String object is first created from the primitive itself, then length is called on the resulting String object. The String object is then sent to garbage collection, but the original primitive remains untouched!

As far as why you and I see different things I find your output most interesting b/c you are using the console in Servoy and I am using raw rhino at the command line (but the same Rhino version mind you).

I'll have to try this all in Servoy specifically.

In interesting conversation though I must say.

[jbader]

@Servoy...is strict mode on or off in Servoy's JS implementation?

[rossent]

If the left-hand side of the instanceof operator is not an object but a primitive, it should return false (like the results which you are seeing in raw Rhino)

In Servoy, for some reason they get "elevated" to objects (by an intrinsic wrapper object) and we get the results which you see in the Interactive Console screen shot.

Trying the same in a browser for example, matches what you see in Rhino. Try it with a simple test like this:

Code: Select all

<html>
    <head></head>
    <body>
        <span onclick="javascript:if(4 instanceof Number){alert('TRUE');}else{alert('FALSE');};">Click Here To Test</span>   
    </body>
</html>


[jbader]

@Servoy, is the below intended or somewhere documented? It makes assertion and explicit type checking pretty tough!

In Servoy, for some reason they get "elevated" to objects (by an intrinsic wrapper object) and we get the results which you see in the Interactive Console screen shot.

@Rossent
Thanks for the extra testing!

[jcompagner]

yes i checked it out and this is a patch that we have in rhino for a long time (at least since servoy 3.5)
the thing is that rhino itself has even comments in the code, this is the code in rhino:

Code: Select all

        // for primitive values on LHS, return false
        // XXX we may want to change this so that
        // 5 instanceof Number == true
        if (! (a instanceof Scriptable))
            return false;


and in servoy it is:

Code: Select all

                // for primitive values on LHS, return false
      // XXX we may want to change this so that
      // 5 instanceof Number == true
      if (!(a instanceof Scriptable))
      {
         Scriptable converted = ScriptRuntime.toObject(cx, cx.topCallScope, a);
         if (converted != null)
         {
            a = converted;
         }
         else
         {
            return false;
         }
      }


The thing is that in java code of rhino there are no primitives .....
Everything is just the object it has to be because the Scriptable.put() objects must have an object

The stupid thing is that i think the way servoy works is what i expect to happen
Because

Code: Select all

var myNumber = 1;
if (myNumber instanceof Number) fixed = myNumber.toFixed(1)


That just works in servoy, as i would expect that it should work..
And i can call all number methods just fine on it also.
So it is a number...
I can even prototype it:

Code: Select all

Number.prototype.myFunction = function(){}
var myNumber = 1;
myNumber.myFunction()


[jcompagner]

yes i think that typeof is just strange...
dont know why you would really us that

typeof is necessary to discover datatypes.

Code: Select all

   function MyObject() {
      
   }
   
   var x = new MyObject();
   
   application.output(typeof(x));
   
   application.output(x instanceof MyObject);
   
   application.output(x instanceof String);


i still don't think typeof really doesnt give me anything in the example above
yes it says "object" ... that i know...
But it doesn't say what object it is... That is instanceof way better.
Besides that typeof returns a string which i find horrible.. Because that means no checks at "compile" time at all.
the instanceof operator can really be used to check a type and that type on the rhs can be checked by tooling.

also your stuff:

Code: Select all

var x = new Boolean(1);
application.output(typeof(x));


that gives you object.. And then what?

[jbader]

@Johan

Now I completely understand what I was seeing. Thank you for sharing the Java code, now I get it (although I can't say I'm a fan of it).

But regarding your comment about you being able to call the methods of Number from a number (primitive), that is supported in JS (w/o your Java hack) and is intended, but it doesn't mean that you are necessarily dealing with a Number vs a number. It just means that JS has temporarily converted your number to Number as opposed to throwing an exception. It takes loose typing to a whole new level; dynamically generating a Number from your primitive to allow you to use the Number object's props and methods! It's a crazy feature, but it is a known one.

For example the following will work just fine even though the variable myNumber is a primitive:

Code: Select all

var myNumber = 1;
myNumber.toFixed(1);

But at least now I understand this, so again thanks a lot!

PS you do realize how hard this makes explicit type checking and assertions in unit testing right?

[jbader]

yes i think that typeof is just strange...
dont know why you would really us that

typeof is necessary to discover datatypes.

Code: Select all

   function MyObject() {
      
   }
   
   var x = new MyObject();
   
   application.output(typeof(x));
   
   application.output(x instanceof MyObject);
   
   application.output(x instanceof String);


i still don't think typeof really doesnt give me anything in the example above
yes it says "object" ... that i know...
But it doesn't say what object it is... That is instanceof way better.
Besides that typeof returns a string which i find horrible.. Because that means no checks at "compile" time at all.
the instanceof operator can really be used to check a type and that type on the rhs can be checked by tooling.

also your stuff:

Code: Select all

var x = new Boolean(1);
application.output(typeof(x));


that gives you object.. And then what?

My point was that you need both. typeof should be used to discover which primitive datatype you are working with, if you are working with a primitive. Instanceof should be used [only] when you have an object and want to know what type of object it is.

[jcompagner]

Code: Select all

var myNumber = 1;
myNumber.toFixed(1);

That example is what i gave to give you a piece of code why i think instanceof should work on that..
Because you can call all methods of that Number type you check for on it!
So purely looking at myNumber from a higher point of view it is a Number ...
It doesn't really matter how you declared it..

PS you do realize how hard this makes explicit type checking and assertions in unit testing right?

No not really can you give me an example why it makes it hard?

But i tested some more and came to a conclusion that some pieces of javascript are just weird:

Code: Select all

var x = true
var y = true
alert(x == y); // TRUE

var x = new Boolean(true)
var y = true
alert(x == y); // TRUE

var x = true
var y = new Boolean(true)
alert(x == y); // TRUE

var x = new Boolean(true)
var y = new Boolean(true)
alert(x == y); // FALSE?????

that is just weird...

[jcompagner]

My point was that you need both. typeof should be used to discover which primitive datatype you are working with, if you are working with a primitive. Instanceof should be used [only] when you have an object and want to know what type of object it is.

and currently in servoy that is not needed if you don't want to use it, you can always use instanceof..
And in my point of view that is way more correct behavior..
But of course you can always use typeof because that is not behavior that is changed right? typeof is "object" for all objects and boolean or number for "primitives"
so you can do:

Code: Select all

if ( typeof(myobject) == "object")  {
    if (myobject instanceof String) {

    }
    else if (myobject instanceof MyObject) {

    }
}
else  {
// primitive
}

besides this, in servoy you have all kind of data coming in and out of the script runtime
What should all those be?
in java they are not primitives ... They are all objects (Integer,Long,String,Date,Double)