var test :String = "0x99"
trace(parseInt(test));
gives :
var /** @type {string} */ test = "0x99";
org.apache.flex.utils.Language.trace(parseInt(test, 10));
which is wrong
I can take a look at it this weekend if no-one else gets to it
On Wed, Mar 15, 2017 at 6:02 PM, Greg Dove <greg.d...@gmail.com> wrote:
> Actually I just checked and it looks like there is a bug in the compiler
> for this
>
>
>
> Greg Dove
> Dove Software Development Ltd
> http://greg-dove.com
>
> On Wed, Mar 15, 2017 at 5:54 PM, Greg Dove <greg.d...@gmail.com> wrote:
>
>> Alex, I agree, it seems whatever prompted this was elsewhere, but the
>> outcome is IMO (a small amount of) better framework code in CSSUtils.
>> I would take this as a small win - nothing is broken, and a utility
>> method is theoretically slightly faster.
>>
>>
>> On Wed, Mar 15, 2017 at 5:19 PM, Alex Harui <aha...@adobe.com> wrote:
>>
>>> Thanks for running the test. Maybe I'm not understanding the issue, but
>>> here's my summary.
>>>
>>> Justin was getting a compile error where code that was known to work
>>> wouldn't compile because there was only one argument passed to parseInt
>>> in
>>> ActionScript source.
>>>
>>> ActionScript defines parseInt as having one required parameter and one
>>> default parameter so it should have compiled.
>>>
>>> Thus, the compile error was likely due to the bad typedefs build Justin
>>> referred to earlier in a separate thread.
>>>
>>> It would not be my recommendation to have us add default parameters to
>>> all
>>> of the places we could for "code clarity" or performance. Folks who write
>>> code in ActionScript should know or can find from the documentation that,
>>> for example, the second parameter to parseInt is optional and thus would
>>> wonder why someone bothered to add it. If the second parameter isn't
>>> there, the assumption should be that the default parameter is used.
>>>
>>> Now, if there is a performance advantage to having the output JS always
>>> set 10 if the second parameter is not specified to parseInt, then that
>>> sounds like a good idea. Please file a JIRA so we don't forget.
>>>
>>> But, IMO, we are writing ActionScript and we should not make a practice
>>> of
>>> supplying default parameters. Please figure out why your typedefs aren't
>>> building and remove the optional parameter for parseInt from CSSUtils.as.
>>>
>>> Thanks,
>>> -Alex
>>>
>>>
>>> On 3/14/17, 8:24 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
>>>
>>> >I think code clarity is one thing, but performance is another - that
>>> >should
>>> >be faster, so I ran a quick check.
>>> >
>>> >I know it can vary across browsers, but
>>> >
>>> >var timeOne = function(){var d=new Date();var b=0; for (var
>>> >i=0;i<10000000;i++) {b= parseInt(""+(127/255)*1000, 10) / 1000;}
>>> >console.log(new Date().getTime()-d.getTime());}
>>> >timeOne()
>>> >approx 715 ms in my chrome over multiple runs
>>> >
>>> >var timeTwo = function(){var d=new Date();var b=0; for (var
>>> >i=0;i<10000000;i++) {b= parseInt(""+(127/255)*1000) / 1000;}
>>> >console.log(new Date().getTime()-d.getTime());}
>>> >timeTwo ()
>>> >approx 870 ms in my chrome over multiple runs
>>> >
>>> >so (within the limits of this *very* basic test) I say keep it, for
>>> >clarity
>>> >and speed (about 20% faster)
>>> >
>>> >On Wed, Mar 15, 2017 at 3:26 PM, Justin Mclean <
>>> jus...@classsoftware.com>
>>> >wrote:
>>> >
>>> >> Hi,
>>> >>
>>> >> > Please revert CSSUtils and investigate why parseInt is requiring the
>>> >> second argument.
>>> >>
>>> >> Even if it is a typedef bug IMO passing the base there makes the code
>>> >> intent clearer as the code is dealing with both base 16 and base 10
>>> >>numbers.
>>> >>
>>> >> This is the code in question:
>>> >> public static function attributeFromColor(value:uint):String
>>> >> {
>>> >> var hexVal:String = value.toString(16);
>>> >> if(value > 16777215)
>>> >> {
>>> >> //rgba -- return rgba notation
>>> >> var rgba:Array = hexVal.match(/.{2}/g);
>>> >> for(var i:int = 0; i < 4; i++)
>>> >> {
>>> >> rgba[i] = parseInt(rgba[i], 16);
>>> >> }
>>> >> rgba[3] = parseInt(""+(rgba[3]/255)*1000, 10) / 1000;
>>> >> return "rgba(" + rgba.join(",") + ")";
>>> >> }
>>> >> return "#" + StringPadder.pad(hexVal,"0",6);
>>> >> }
>>> >>
>>> >> I added the “,10” to the second parseInt.
>>> >>
>>> >> What do others think? Should it stay or should it go?
>>> >>
>>> >> Thanks,
>>> >> Justin
>>>
>>>
>>
>
