/customers/iconara.net/iconara.net/httpd.www/blog/wp-content/plugins/wp-super-cache/wp-cache-phase1.php Warning: Cannot modify header information - headers already sent by (output started at /customers/4/c/9/iconara.net/httpd.www/blog/wp-content/advanced-cache.php:1) in /customers/4/c/9/iconara.net/httpd.www/blog/wp-includes/feed-rss2-comments.php on line 8 Comments on: Architectural Atrocities, part 7 / MXMLC WTF (6): Some types are less equal than others http://blog.iconara.net/2007/03/16/architectural-atrocities-part-7-some-types-are-less-equal-than-others/ Thu, 05 Jul 2012 13:41:39 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Troy http://blog.iconara.net/2007/03/16/architectural-atrocities-part-7-some-types-are-less-equal-than-others/comment-page-1/#comment-4725 Troy Fri, 10 Aug 2007 01:06:38 +0000 http://blog.iconara.net/2007/03/16/architectural-atrocities-part-7-some-types-are-less-equal-than-others/#comment-4725 <p>I feel your pain, I have a background and Java/C# and many years of AS2 mental yoga, hitting the issues you outlined left me going WTF? Shortly after I found I couldn't extend core classes.</p> <p>In doing some performance testing in comparisons, uint/int seem to be hybrid/bastards they are sometimes value mock primitives types other time reference able full blown Objects types.</p> <p>I presume they made this choice, is to appeal to C/Java/.Net programmers making the transition, porting code from other languages. They are in spirit like those concepts in other languages.</p> I feel your pain, I have a background and Java/C# and many years of AS2 mental yoga, hitting the issues you outlined left me going WTF? Shortly after I found I couldn’t extend core classes.

In doing some performance testing in comparisons, uint/int seem to be hybrid/bastards they are sometimes value mock primitives types other time reference able full blown Objects types.

I presume they made this choice, is to appeal to C/Java/.Net programmers making the transition, porting code from other languages. They are in spirit like those concepts in other languages.

]]>
By: Theo http://blog.iconara.net/2007/03/16/architectural-atrocities-part-7-some-types-are-less-equal-than-others/comment-page-1/#comment-4559 Theo Tue, 12 Jun 2007 06:13:02 +0000 http://blog.iconara.net/2007/03/16/architectural-atrocities-part-7-some-types-are-less-equal-than-others/#comment-4559 <p>Well, NaN works for Numbers, but not for ints and uints. When I wrote it I may have missed the NaN/Number case.</p> Well, NaN works for Numbers, but not for ints and uints. When I wrote it I may have missed the NaN/Number case.

]]>
By: matthew http://blog.iconara.net/2007/03/16/architectural-atrocities-part-7-some-types-are-less-equal-than-others/comment-page-1/#comment-4552 matthew Mon, 11 Jun 2007 20:51:05 +0000 http://blog.iconara.net/2007/03/16/architectural-atrocities-part-7-some-types-are-less-equal-than-others/#comment-4552 <p>I agree. Also, it seems to me that since uint and int are not actually primitives, they should be capitalized like everything else.</p> <p>However, I'm not sure I understand what you mean by "I can’t think of a way of using default parameter values to implement optional parameters if those parameters are of type Number, int or uint...With the number types you can’t...use NaN."</p> I agree. Also, it seems to me that since uint and int are not actually primitives, they should be capitalized like everything else.

However, I’m not sure I understand what you mean by “I can’t think of a way of using default parameter values to implement optional parameters if those parameters are of type Number, int or uint…With the number types you can’t…use NaN.”

]]>
By: Theo http://blog.iconara.net/2007/03/16/architectural-atrocities-part-7-some-types-are-less-equal-than-others/comment-page-1/#comment-3359 Theo Fri, 16 Mar 2007 20:14:34 +0000 http://blog.iconara.net/2007/03/16/architectural-atrocities-part-7-some-types-are-less-equal-than-others/#comment-3359 <p>Although your explanation may be correct, I don't care about where they are stored, it's still a language specification issue. ActionScript and ECMAScript (which are the same to me, I don't particularly critisise either over the other) should not let technical details get in the way of consistency. If they are primitives, don't treat them as objects, and if they are objects don't treat them like primitives.</p> <p>And about heap vs stack, you are probably right in that the objects are stored in the web browser's heap since that is where the ActionScript interpreter lives, but that dosen't mean that they are stored in the ActionScript interpreter's heap, because those are very different things. You mention that AVM is a virtual machine, but you forget that that means that it has it's own (virtual) registers, heap and stack and just because they are all allocated in the browser's heap doesn't mean that they are equal.</p> <p>Now, I'm pretty sure that all objects in ActionScript are actually stored in the heap (the AS interpreter's heap, that is), since there would have to be some real clever magic for closures to work otherwise.</p> <hr /> <p>I do agree that a boolean with the value null can be a bit odd at first glance, but you just have to think of null as "not set" (which is what "undefined" was supposed to mean), and it should be a runtime error to use such a boolean, just as it should be when trying to run a method on something that is null. Compare this to Boolean (not boolean) in Java, or how you would store booleans in a database (where you can disallow NULL, but also use it to mean "not set", which is handy).</p> <p>And no, I don't want a higher level structure representing my booleans. I want booleans to be booleans, and I want them to be objects, just like they are. But I want the compiler and the runtime to accept boolean references to be null, because I see no reason why not.</p> <p>An example (similar to the code that got me to write this post) of where I would want to have a primitive with the value null:</p> <p>function something( aValue : Number = null ) : void { if ( aValue == null ) { aValue = 3; } // ... }</p> <p>Another example would be null as the default value of all instance variables, so that a runtime error was raised if something wasn't initialised properly. I've never liked the default values that primitives get, it makes for sloppy initialisation.</p> <p>In the example above I could use Infinity or NaN (testing with isNaN) or a magic number, but that is not what this is about, this is a discussion about the language and API, not the specific problem. I find the above example perfectly reasonable, because if I change "Number" to "Object" it would compile, and nothing that the runtime can tell me (using describeType or testing with "... is Object", for example) can tell me why it wouldn't work.</p> <p>If you instead try this code:</p> <p>private function something( aValue : Object = null ) : void { if ( aValue == null ) { aValue = 3; } // ... }</p> <p>It would compile, but more importantly, if you add</p> <p>trace(describeType(aValue));</p> <p>It will tell you that aValue is of type int. So it's only a matter of the type of the variable, nothing else. This is really, really, ugly and inconsistent.</p> Although your explanation may be correct, I don’t care about where they are stored, it’s still a language specification issue. ActionScript and ECMAScript (which are the same to me, I don’t particularly critisise either over the other) should not let technical details get in the way of consistency. If they are primitives, don’t treat them as objects, and if they are objects don’t treat them like primitives.

And about heap vs stack, you are probably right in that the objects are stored in the web browser’s heap since that is where the ActionScript interpreter lives, but that dosen’t mean that they are stored in the ActionScript interpreter’s heap, because those are very different things. You mention that AVM is a virtual machine, but you forget that that means that it has it’s own (virtual) registers, heap and stack and just because they are all allocated in the browser’s heap doesn’t mean that they are equal.

Now, I’m pretty sure that all objects in ActionScript are actually stored in the heap (the AS interpreter’s heap, that is), since there would have to be some real clever magic for closures to work otherwise.


I do agree that a boolean with the value null can be a bit odd at first glance, but you just have to think of null as “not set” (which is what “undefined” was supposed to mean), and it should be a runtime error to use such a boolean, just as it should be when trying to run a method on something that is null. Compare this to Boolean (not boolean) in Java, or how you would store booleans in a database (where you can disallow NULL, but also use it to mean “not set”, which is handy).

And no, I don’t want a higher level structure representing my booleans. I want booleans to be booleans, and I want them to be objects, just like they are. But I want the compiler and the runtime to accept boolean references to be null, because I see no reason why not.

An example (similar to the code that got me to write this post) of where I would want to have a primitive with the value null:

function something( aValue : Number = null ) : void { if ( aValue == null ) { aValue = 3; } // … }

Another example would be null as the default value of all instance variables, so that a runtime error was raised if something wasn’t initialised properly. I’ve never liked the default values that primitives get, it makes for sloppy initialisation.

In the example above I could use Infinity or NaN (testing with isNaN) or a magic number, but that is not what this is about, this is a discussion about the language and API, not the specific problem. I find the above example perfectly reasonable, because if I change “Number” to “Object” it would compile, and nothing that the runtime can tell me (using describeType or testing with “… is Object”, for example) can tell me why it wouldn’t work.

If you instead try this code:

private function something( aValue : Object = null ) : void { if ( aValue == null ) { aValue = 3; } // … }

It would compile, but more importantly, if you add

trace(describeType(aValue));

It will tell you that aValue is of type int. So it’s only a matter of the type of the variable, nothing else. This is really, really, ugly and inconsistent.

]]>
By: Mark Lapasa http://blog.iconara.net/2007/03/16/architectural-atrocities-part-7-some-types-are-less-equal-than-others/comment-page-1/#comment-3358 Mark Lapasa Fri, 16 Mar 2007 19:26:14 +0000 http://blog.iconara.net/2007/03/16/architectural-atrocities-part-7-some-types-are-less-equal-than-others/#comment-3358 <p>Re: No autoboxing in Flash.</p> <p>I am no Flash Player engineer but I am pretty sure there is a good reason why autoboxing is not an ActionScript feature. This is my explanation...</p> <p>Primatives in Java are stored on the stack which is the 2nd fastest place for accessing data. Objects that are instantiated using the 'new' kewyword are stored in the 3rd fastest place in memory, the heap. In order for primatives to be manifested into objects (for the purposes of late binding, is my guess), they need to be in the same memory space as instantiable objects. Thus, primatives get wraped into their respective wrapper classes in the heap.</p> <p>i.e. an 'int' in the stack, will get stored as an 'Integer' in the heap.</p> <p>(J2SE5 now introduces autoboxing to handle this type of conversion because in the past it used to be a lot more explicit coding/downcasting.)</p> <p>The Flash Player, being the C++ plug-in it is, is probably stored in the memory's heap. Because the "Flash Virtual Machine" (AVM) runs under the same process as the browser, it's working memory space is the heap and cannot write to the stack. Thus when the AVM creates it's objects or primatives, it's really writing it in the heap. I mention all of this because in this case, autoboxing does not make sense in Flash.</p> <hr /> <p>Re: An object of type Number, int, uint and Boolean cannot contain null.</p> <p>If you don't like not being able to set a low-level data type to null, there is no reason why you can't leverage the OO-ness of ActionScript and be able to create your own high-level data abstraction that will satisfy your requirement.</p> <p>I find the idea of Boolean storing a 3rd value null, in addition to true and false to be illogical. It's like asking for a 3-way light switch that's either on, off, or ... null.</p> <p>If you could provide a use-case where having a primative set to null would be an advantage and that the work-arounds would have a detremental affect on the O-running time or code readability/maintence, that would be great.</p> <hr /> <p>Having explained that primatives are probably heap objects, this could add fuel to your argument that primatives are really ought to be able to set to null. I understand maybe you might want to have a primative variable that is stripped of any data by deferencing it to null. However, really your beef should not be with ActionScript but with ECMA, the standard which ActionScript strives for...specifically ECMA-262.</p> Re: No autoboxing in Flash.

I am no Flash Player engineer but I am pretty sure there is a good reason why autoboxing is not an ActionScript feature. This is my explanation…

Primatives in Java are stored on the stack which is the 2nd fastest place for accessing data. Objects that are instantiated using the ‘new’ kewyword are stored in the 3rd fastest place in memory, the heap. In order for primatives to be manifested into objects (for the purposes of late binding, is my guess), they need to be in the same memory space as instantiable objects. Thus, primatives get wraped into their respective wrapper classes in the heap.

i.e. an ‘int’ in the stack, will get stored as an ‘Integer’ in the heap.

(J2SE5 now introduces autoboxing to handle this type of conversion because in the past it used to be a lot more explicit coding/downcasting.)

The Flash Player, being the C++ plug-in it is, is probably stored in the memory’s heap. Because the “Flash Virtual Machine” (AVM) runs under the same process as the browser, it’s working memory space is the heap and cannot write to the stack. Thus when the AVM creates it’s objects or primatives, it’s really writing it in the heap. I mention all of this because in this case, autoboxing does not make sense in Flash.


Re: An object of type Number, int, uint and Boolean cannot contain null.

If you don’t like not being able to set a low-level data type to null, there is no reason why you can’t leverage the OO-ness of ActionScript and be able to create your own high-level data abstraction that will satisfy your requirement.

I find the idea of Boolean storing a 3rd value null, in addition to true and false to be illogical. It’s like asking for a 3-way light switch that’s either on, off, or … null.

If you could provide a use-case where having a primative set to null would be an advantage and that the work-arounds would have a detremental affect on the O-running time or code readability/maintence, that would be great.


Having explained that primatives are probably heap objects, this could add fuel to your argument that primatives are really ought to be able to set to null. I understand maybe you might want to have a primative variable that is stripped of any data by deferencing it to null. However, really your beef should not be with ActionScript but with ECMA, the standard which ActionScript strives for…specifically ECMA-262.

]]>