Breaking change: parseInt/parseDouble will be removed from dart:math. Use int.parse/double.parse instead.

[Lasse R.H. Nielsen]

Greetings all.

We are removing parseInt and parseDouble from the dart:math library, and making them static methods called "parse" on the int and double classes.

The original reason, from long ago, for putting them in Math was that int and double were interfaces, and couldn't contain static methods. Now that we are converting all interfaces to abstract classes, we will move those functions where they belong.

The dart:math parseInt/parseDouble functions will still work, but they will be removed in about a week.

The functions now have documentation too! Please do report if it is confusing or misleading in any way.

Cheers

/L

--
Lasse R.H. Nielsen - l...@google.com  

'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 København K - Denmark - CVR nr. 28 86 69 84

[Matthew Butler]

What build does the new syntax start working? I'm using 12144 and the method signature exists, however when I try to use int.parseInt('42'); I get Unresolved static method 'parseInt'

Thanks,
Matt

[John Evans]

All these changes are welcomed! I second Matt's request that, when possible, they be accompanied by a "this change will occur as of build x" statement.

[Matthew Butler]

On Monday, September 17, 2012 9:34:26 AM UTC-3, John Evans wrote:

All these changes are welcomed! I second Matt's request that, when possible, they be accompanied by a "this change will occur as of build x" statement.

Agreed, I understand we can't say "feature will be removed in build xxx" but at the least that "The new way is available as of build yyy". In this case it was particularly confusing since the signature was already provided in the interface/abstract class, but left uncompleted until a later build. :) Out of the greatest respect for all the work done.

Matt

[Lasse R.H. Nielsen]

On Mon, Sep 17, 2012 at 2:25 PM, Matthew Butler <butler....@gmail.com> wrote:

On Monday, September 17, 2012 5:19:30 AM UTC-3, Lasse Reichstein Holst Nielsen wrote:

Greetings all.

We are removing parseInt and parseDouble from the dart:math library, and making them static methods called "parse" on the int and double classes.

The original reason, from long ago, for putting them in Math was that int and double were interfaces, and couldn't contain static methods. Now that we are converting all interfaces to abstract classes, we will move those functions where they belong.

The dart:math parseInt/parseDouble functions will still work, but they will be removed in about a week.

The functions now have documentation too! Please do report if it is confusing or misleading in any way.

Cheers

/L

What build does the new syntax start working? I'm using 12144 and the method signature exists, however when I try to use int.parseInt('42'); I get Unresolved static method 'parseInt'

The change was committed in revision 12417, so it should be available.

The new functions are called just "parse", so try  int.parse('42')  instead.

And duly noted: I'll try to give the revision number of changes in the future when posting about changes after the fact.

Cheers!

/L

[Matthew Butler]

On Monday, September 17, 2012 10:24:27 AM UTC-3, Lasse Reichstein Holst Nielsen wrote:

The change was committed in revision 12417, so it should be available.

The new functions are called just "parse", so try  int.parse('42')  instead.

Ah so not in my current integration build but in the continuous. And Opps bad me for not paying closer attention to what I'm auto-completing. My apologies.

And duly noted: I'll try to give the revision number of changes in the future when posting about changes after the fact.

Greatly appreciated! :)

Cheers!

/L

-- 

Lasse R.H. Nielsen - l...@google.com  

'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 København K - Denmark - CVR nr. 28 86 69 84

Matt 

[Bob Nystrom]

I love this change.

Lasse, one question: Why make "parse()" static methods and not named constructors?

- bob

--
Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart
 
 

[Ladislav Thon]

> Lasse, one question: Why make "parse()" static methods and not named constructors?

Exactly. Other classes use the 'fromString' constructor and while I'd love it to be called 'parse', it should still be a constructor.

LT

[Lasse R.H. Nielsen]

On Tue, Sep 18, 2012 at 6:14 AM, Ladislav Thon <lad...@gmail.com> wrote:

> Lasse, one question: Why make "parse()" static methods and not named constructors?

Exactly. Other classes use the 'fromString' constructor and while I'd love it to be called 'parse', it should still be a constructor.

I thought about making it a constructor, but it didn't feel right for int or double values.

 

I see "parse" as a utility function more than a constructor, probably because int and double don't really have constructors otherwise. You don't create an integer, you discover it.

Also, currently the only way to check if a string is a number literal is to call parse and see if it throws (but I'm not entirely satisfied with that!), and I don't like constructors that throw on anything but programming errors.

And you don't have to write "new" in front of it this way, for no particular gain.

There is no single hard reason that makes it obviously not a constructor, but a bunch of smaller issues that together make me prefer it as a static function.

Cheers

/L

-- 

[Sean Eagan]

On Tue, Sep 18, 2012 at 3:07 AM, Lasse R.H. Nielsen <l...@google.com> wrote:

Also, currently the only way to check if a string is a number literal is to call parse and see if it throws (but I'm not entirely satisfied with that!), and I don't like constructors that throw on anything but programming errors.

I agree it would be more convenient to have them return null instead of throw, and it would be strange if a constructor ever returned null.

A couple questions:

Why double.parse instead of num.parse ?  I think double.parse would encourage people to use "double" as a type annotation which according to the style guide is bad.

It looks like (see http://dartbug.com/233) there is a plan for int.parseRadix (num/double.parseRadix too ?), why not just use an optional radix parameter ?

Also, I assume "package:intl" will contain something like:

NumFormat

IntFormat

If so, then why do we need any of the following:

int.parse

int.parseRadix

double.parse

num.toRadixString

num.toStringAsExponential

num.toStringAsFixed

num.toStringAsPrecision

One reason is because placing this functionality in a "dart:" library allows it to be optimized to native JavaScript/C++, but it could be changed to "dart:intl", which would also allow it to use pre-installed localization data (only in the VM for now, but also in dart2js when browsers support the EcmaScript Internationalization API) instead of having to download it over HTTP at runtime.

Cheers,

Sean Eagan

[Florian Loitsch]

On Tue, Sep 18, 2012 at 4:55 PM, Sean Eagan <seane...@gmail.com> wrote:

On Tue, Sep 18, 2012 at 3:07 AM, Lasse R.H. Nielsen <l...@google.com> wrote:

Also, currently the only way to check if a string is a number literal is to call parse and see if it throws (but I'm not entirely satisfied with that!), and I don't like constructors that throw on anything but programming errors.

I agree it would be more convenient to have them return null instead of throw, and it would be strange if a constructor ever returned null.

A couple questions:

Why double.parse instead of num.parse ?  I think double.parse would encourage people to use "double" as a type annotation which according to the style guide is bad.

I think we should have an additional "num.parse" that returns either a double or int, depending on the string.

for example:

num.parse("1") => 1 // int. 

num.parse("1.0") => 1.0 // double.

double.parse("1") => 1.0

It looks like (see http://dartbug.com/233) there is a plan for int.parseRadix (num/double.parseRadix too ?), why not just use an optional radix parameter ?

Also, I assume "package:intl" will contain something like:

NumFormat

IntFormat

If so, then why do we need any of the following:

int.parse

int.parseRadix

double.parse

num.toRadixString

num.toStringAsExponential

num.toStringAsFixed

num.toStringAsPrecision

One reason is because placing this functionality in a "dart:" library allows it to be optimized to native JavaScript/C++, but it could be changed to "dart:intl", which would also allow it to use pre-installed localization data (only in the VM for now, but also in dart2js when browsers support the EcmaScript Internationalization API) instead of having to download it over HTTP at runtime.

Cheers,

Sean Eagan

--

Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart
 
 

--
Give a man a fire and he's warm for the whole day,
but set fire to him and he's warm for the rest of his life. - Terry Pratchett

[Lasse R.H. Nielsen]

On Tue, Sep 18, 2012 at 6:04 PM, Florian Loitsch <floi...@google.com> wrote:
>
> On Tue, Sep 18, 2012 at 4:55 PM, Sean Eagan <seane...@gmail.com> wrote:
>>
>>
>> On Tue, Sep 18, 2012 at 3:07 AM, Lasse R.H. Nielsen <l...@google.com> wrote:
>>>
>>>
>>> Also, currently the only way to check if a string is a number literal is to call parse and see if it throws (but I'm not entirely satisfied with that!), and I don't like constructors that throw on anything but programming errors.
>>
>>
>> I agree it would be more convenient to have them return null instead of throw, and it would be strange if a constructor ever returned null.
>>
>> A couple questions:
>>
>> Why double.parse instead of num.parse ? I think double.parse would encourage people to use "double" as a type annotation which according to the style guide is bad.
>
> I think we should have an additional "num.parse" that returns either a double or int, depending on the string.
> for example:
> num.parse("1") => 1 // int.
> num.parse("1.0") => 1.0 // double.
> double.parse("1") => 1.0

Reasonable.
It should probably act the same as the Dart parser to distinguish int
literals from double literals (if it contains "." or an exponential,
it's a double!).

For example "18014398509481985.3" is a double, even if the closest
double is 18014398509481984.0, and the closest int is
18014398509481985, which is closer.

/L

>
>
>>
>> It looks like (see http://dartbug.com/233) there is a plan for int.parseRadix (num/double.parseRadix too ?), why not just use an optional radix parameter ?
>>
>> Also, I assume "package:intl" will contain something like:
>>
>> NumFormat
>> IntFormat
>>
>> If so, then why do we need any of the following:
>>
>> int.parse
>> int.parseRadix
>> double.parse
>> num.toRadixString
>> num.toStringAsExponential
>> num.toStringAsFixed
>> num.toStringAsPrecision
>>
>> One reason is because placing this functionality in a "dart:" library allows it to be optimized to native JavaScript/C++, but it could be changed to "dart:intl", which would also allow it to use pre-installed localization data (only in the VM for now, but also in dart2js when browsers support the EcmaScript Internationalization API) instead of having to download it over HTTP at runtime.
>>
>> Cheers,
>> Sean Eagan
>>
>> --
>> Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart
>>
>>
>
>
>
>
> --
> Give a man a fire and he's warm for the whole day,
> but set fire to him and he's warm for the rest of his life. - Terry Pratchett
>
> --
> Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart
>
>




--

[Bob Nystrom]

On Tue, Sep 18, 2012 at 7:55 AM, Sean Eagan <seane...@gmail.com> wrote:

On Tue, Sep 18, 2012 at 3:07 AM, Lasse R.H. Nielsen <l...@google.com> wrote:

Also, currently the only way to check if a string is a number literal is to call parse and see if it throws (but I'm not entirely satisfied with that!), and I don't like constructors that throw on anything but programming errors.

I agree it would be more convenient to have them return null instead of throw, and it would be strange if a constructor ever returned null.

But given that all types are nullable in Dart, I worry that that makes it way too easy for a parse to fail and not realize that until much later in the program when you try to do something with the number. I like that parse() throws.

Cheers!

- bob

[Matthew Butler]

On Monday, September 17, 2012 5:19:30 AM UTC-3, Lasse Reichstein Holst Nielsen wrote:

Out of curiosity, is this something that can/should be added to the migration tool?

Matt 

[Alan Knight]

Intl does contain a NumberFormat already that's half-implemented. I think that it would be more that you'd specify a format and a locale rather than having separate classes. But that's heavyweight machinery, at least up until the point where we'd have access to the internationalization code that's already in all the browsers, just hidden from us. Well, even then it would be heavyweight, but presumably fast. So that may not be what you want for simple, locale-independent parsing. It does put an upper bound on how much sophistication you'd want to put into basic parsing methods on the numeric classes.

On Tue, Sep 18, 2012 at 7:55 AM, Sean Eagan <seane...@gmail.com> wrote:

--

[Konstantin Scheglov]

  Corresponding Clean-Up was added to the Editor (continuous build, not in integration yet).

--
Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart
 
 

--
Konstantin Scheglov

Software Engineer

Google, Inc.

[Matthew Butler]

On Thursday, September 20, 2012 11:35:19 AM UTC-3, Konstantin Scheglov wrote:

  Corresponding Clean-Up was added to the Editor (continuous build, not in integration yet).

That's fantastic! Thanks!

 

Konstantin Scheglov

Software Engineer

Google, Inc.

Matt 

[Vitor Ventura]

I believe there is an error in the documentation. It seems like the radix is a mandatory argument even being a named one.

https://groups.google.com/a/dartlang.org/forum/?fromgroups=#!topic/misc/IHFn9rKP4dE

[Zdeslav Vojkovic]

Do you have a test case?

I have just tried:

int x = int.parse("0x12");
print("$x"); // => 18

Dart SDK version 0.5.3.0_r22223

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new
 
 

[Vitor Ventura]

You are right I sorry about that.