Could you explain to me what the great advantage is of boxing natives, what is the intended use for this? I’ve been using my own boxed primitives in my JavaScript framework since 2002 and built http://obsurvey.com with it. I needed to box all the types so I could fire events every time anything is altered in the natives. I just use .setValue and .getValue and map all the methods to simple method calls. No DOM interaction is involved at all.
As far as I can see you are introducing a lot of possibilities for errors caused by different browsers. Why do I need this much larger and more complex codebase that fusebox is?
FuseJS uses sandboxed natives so its native extensions don’t pollute the global object. This allows for better third-party compatibility because I know it won’t step on others code. The arrays, numbers, strings, and other sandboxed natives are real natives and can be treated like their non-sandboxed counterparts. For example they have the same internal [[Class]] property as natives and things like the array.length property work correctly.
Fusebox is ~3kb minified+gzipped.
The sandboxing techniques I use are pretty stable too. The ActiveX object I use has been supported since IE4, the use of __proto__ is supported in lots of JS engines (meaning serverside JS can be supported too) and goes back to ancient versions of Netscape, and the iframe technique, while a bit challenging at first, has proven stable through at least 10 different releases of Opera.
I would love to see your solution.
Do you have it on github ?
“The arrays, numbers, strings, and other sandboxed natives are real natives and can be treated like their non-sandboxed counterparts. For example they have the same internal [[Class]] property as natives and things like the array.length property work correctly.”
Sorry for playing the devils advocate again, but:
Actually in my code it’s important that I can distinguish my boxed types from the native ones, so I don’t want them to have the same [[Class]] property. Why is that important?
Also about the length property I just call length() with parenthesis. You have an awfull lot of code just to get the same [[Class]] and avoid putting parenthesis after length.
Can you index a boxed array like a native array:
myFuseboxArray[0] = “test”;
and if so, can you fire an event when an element is set?
Having the correct [[Class]] is important because it allows for popular type detection using {}.toString.call(value).
You can detect the difference between Fuseboxed natives and document natives by looking at their constructor property.
Yes, myFuseboxArray[0] = "test";
works.
I’m sure you could fire an event with proper getter/setter modifications but it wouldn’t be cross-browser.
Yes, myFuseBoxArray[0]++ will work but it will convert the Fuseboxed number to a primitive.
Just like var n = new Number(0); n++; typeof n === "number";.
As for the events, I don’t think there is a cross-browser way to do it, but you can check out MDC docs
To bad it’s converted into a primitive, then I can’t use it. And I really need crossbrowser addition of the observer pattern on all changes to my boxed types. Guess I’ll stick with my solution for now. But still. Interesting stuff.
My solution is closed source so far. I haven’t polished it for opensourcing it.
I can see that extending the native types would be nice without polluting the global namespace, and don’t get me wrong I think your solution is a fine piece of programming, I can see you put a lot of effort into it.
But I think 3Kb minified JS, DOM dependance and different solutions for different browsers is quite a high price to pay for it, plus having to maintain the code. I Just use helper classes that take the primitive as it’s first argument and the methods arguments next, and all my helper classes are maybe 1-200 lines of code, and I’ve hardly touched them since I made them in 2002.
The main reason I boxed the native types was to be able to react to changes to them, secondary to extend them. Could fusebox be altered to fire an event every time one of the methods is called? So if I have a FuseJS Array, calling .splice (or any other method) on that array would fire any events attached with an observer pattern? That would be really useful.
Only the iframe technique requires the DOM, ActiveX and __proto__ do not.
I don’t see anything wrong with having different solutions for browsers/environments.
Maintenance is not an issue for the ActiveX (tested to work in IE 5.5 which was released in 2000)
or the __proto__ (tested to work in the earliest version of Netscape, 7.0.2 ~2002, I could find at the moment) branches.
The iframe branch is the only part that may need maintaining. Currently Opera is the only browser using the iframe
branch, excluding IE using file:// protocol, and its issues are at least consistent between 9.5-10.
As for triggering events, yes you could alter the method wrapping code to include a call to fire an event.
Well call me sceptical, but beeing dependant on ActiveX might prove to be problematic in the future.
Industry Average: “about 15 – 50 errors per 1000 lines of delivered
code.” He further says this is usually representative of code that has some
level of structured programming behind it, but probably includes a mix of
coding techniques. http://amartester.blogspot.com/2007/04/bugs-per-lines-of-code.html
The method that creates the sandbox is ~50 lines of code
I don’t think you have anything to worry about. The htmlfile ProgID is baked into windows. The MSDN docs state:
In certain cases, the ProgID associated with a file extension should not be changed. For example, the ProgID for the .htm file extension (progid = htmlfile) is hard coded in a number of places in the operating system, and is widely known and used in association with .htm and .html files.
Also the new ActiveXObject('htmlfile'); has worked for the last 13 years with no sign of being dropped anytime soon.
You can even access the control via VBScript (which is still supported in IE9).
jdalton 
Allan Ebdrup 3:33 am on January 22, 2010 | # |
Could you explain to me what the great advantage is of boxing natives, what is the intended use for this? I’ve been using my own boxed primitives in my JavaScript framework since 2002 and built http://obsurvey.com with it. I needed to box all the types so I could fire events every time anything is altered in the natives. I just use .setValue and .getValue and map all the methods to simple method calls. No DOM interaction is involved at all.
As far as I can see you are introducing a lot of possibilities for errors caused by different browsers. Why do I need this much larger and more complex codebase that fusebox is?
jdalton 4:15 pm on January 22, 2010 | # |
FuseJS uses sandboxed natives so its native extensions don’t pollute the global object. This allows for better third-party compatibility because I know it won’t step on others code. The arrays, numbers, strings, and other sandboxed natives are real natives and can be treated like their non-sandboxed counterparts. For example they have the same internal
[[Class]]property as natives and things like the array.length property work correctly.Fusebox is ~3kb minified+gzipped.
The sandboxing techniques I use are pretty stable too. The ActiveX object I use has been supported since IE4, the use of
__proto__is supported in lots of JS engines (meaning serverside JS can be supported too) and goes back to ancient versions of Netscape, and the iframe technique, while a bit challenging at first, has proven stable through at least 10 different releases of Opera.I would love to see your solution.
Do you have it on github ?
Allan Ebdrup 9:15 am on January 25, 2010 | #
“The arrays, numbers, strings, and other sandboxed natives are real natives and can be treated like their non-sandboxed counterparts. For example they have the same internal [[Class]] property as natives and things like the array.length property work correctly.”
Sorry for playing the devils advocate again, but:
Actually in my code it’s important that I can distinguish my boxed types from the native ones, so I don’t want them to have the same [[Class]] property. Why is that important?
Also about the length property I just call length() with parenthesis. You have an awfull lot of code just to get the same [[Class]] and avoid putting parenthesis after length.
Can you index a boxed array like a native array:
myFuseboxArray[0] = “test”;
and if so, can you fire an event when an element is set?
jdalton 10:07 am on January 25, 2010 | #
Having the correct
[[Class]]is important because it allows for popular type detection using{}.toString.call(value).You can detect the difference between Fuseboxed natives and document natives by looking at their
constructorproperty.Yes,
myFuseboxArray[0] = "test";works.
I’m sure you could fire an event with proper getter/setter modifications but it wouldn’t be cross-browser.
I appreciate your questions. Keep them coming
Allan Ebdrup 12:08 pm on January 25, 2010 | #
”
Yes,
myFuseboxArray[0] = “test”;
works.
I’m sure you could fire an event with proper getter/setter modifications but it wouldn’t be cross-browser.
”
Ok, I’ll keep the questions coming
so if myFuseBoxArray[0] contains a fusebox number I could do
myFuseBoxArray[0]++
And have an event fire in the fusebox number?
jdalton 9:26 am on January 26, 2010 | #
Yes,
myFuseBoxArray[0]++will work but it will convert the Fuseboxed number to a primitive.Just like
var n = new Number(0); n++; typeof n === "number";.As for the events, I don’t think there is a cross-browser way to do it, but you can check out MDC docs
Allan Ebdrup 3:56 am on January 27, 2010 | #
To bad it’s converted into a primitive, then I can’t use it. And I really need crossbrowser addition of the observer pattern on all changes to my boxed types. Guess I’ll stick with my solution for now. But still. Interesting stuff.
Allan Ebdrup 4:47 pm on January 22, 2010 | # |
My solution is closed source so far. I haven’t polished it for opensourcing it.
I can see that extending the native types would be nice without polluting the global namespace, and don’t get me wrong I think your solution is a fine piece of programming, I can see you put a lot of effort into it.
But I think 3Kb minified JS, DOM dependance and different solutions for different browsers is quite a high price to pay for it, plus having to maintain the code. I Just use helper classes that take the primitive as it’s first argument and the methods arguments next, and all my helper classes are maybe 1-200 lines of code, and I’ve hardly touched them since I made them in 2002.
The main reason I boxed the native types was to be able to react to changes to them, secondary to extend them. Could fusebox be altered to fire an event every time one of the methods is called? So if I have a FuseJS Array, calling .splice (or any other method) on that array would fire any events attached with an observer pattern? That would be really useful.
jdalton 1:41 am on January 23, 2010 | # |
Only the iframe technique requires the DOM, ActiveX and __proto__ do not.
I don’t see anything wrong with having different solutions for browsers/environments.
Maintenance is not an issue for the ActiveX (tested to work in IE 5.5 which was released in 2000)
or the __proto__ (tested to work in the earliest version of Netscape, 7.0.2 ~2002, I could find at the moment) branches.
The iframe branch is the only part that may need maintaining. Currently Opera is the only browser using the iframe
branch, excluding IE using file:// protocol, and its issues are at least consistent between 9.5-10.
As for triggering events, yes you could alter the method wrapping code to include a call to fire an event.
Allan Ebdrup 1:56 pm on January 24, 2010 | #
Well call me sceptical, but beeing dependant on ActiveX might prove to be problematic in the future.
Industry Average: “about 15 – 50 errors per 1000 lines of delivered
code.” He further says this is usually representative of code that has some
level of structured programming behind it, but probably includes a mix of
coding techniques.
http://amartester.blogspot.com/2007/04/bugs-per-lines-of-code.html
jdalton 4:42 pm on January 24, 2010 | #
The method that creates the sandbox is ~50 lines of code
I don’t think you have anything to worry about. The
htmlfileProgID is baked into windows. The MSDN docs state:Also the
new ActiveXObject('htmlfile');has worked for the last 13 years with no sign of being dropped anytime soon.You can even access the control via VBScript (which is still supported in IE9).
Allan Ebdrup 3:48 pm on January 31, 2010 | #
Do your boxed types work on iPad? mine do
jdalton 2:16 pm on February 1, 2010 | #
Yes Fuseboxed natives work on the iPhone and should work fine on the iPad.
Allan Ebdrup 12:10 pm on January 25, 2010 | # |
By the way, you can read about some of the stuff I’ve done in my JavaScript framework here:
http://obsurvey.com/UIA.aspx
Allan Ebdrup 11:53 pm on January 22, 2010 | # |
You should do a fifth video entitled “These are some neat things you can do with boxed native types”, would be great.
jdalton 1:42 am on January 23, 2010 | # |
That is a great idea. I will seriously consider it.
Allan Ebdrup 12:54 pm on January 26, 2010 | #
Really looking forward to it
Allan Ebdrup 1:28 am on February 3, 2010 | # |
Here my “This is a great thing you can do with boxed types” video http://screenr.com/O4d