Skip to content
This repository was archived by the owner on Apr 12, 2024. It is now read-only.

Expressions don't understand Infinity #9492

Closed
Alexsey opened this issue Oct 8, 2014 · 18 comments
Closed

Expressions don't understand Infinity #9492

Alexsey opened this issue Oct 8, 2014 · 18 comments

Comments

@Alexsey
Copy link
Contributor

Alexsey commented Oct 8, 2014

Infinity in expressions is not treating as Infinity number, but as variable
Plunker
So it even can be override
Plunker

@btford
Copy link
Contributor

btford commented Oct 8, 2014

@IgorMinar @caitp do we want to expose Infinity in Angular expressions?

@btford btford added this to the Backlog milestone Oct 8, 2014
@caitp
Copy link
Contributor

caitp commented Oct 8, 2014

I'm not sure what the use case is, but I don't think it's that bad to add it. On the other hand, the parser doesn't understand NaN either, so maybe we don't need it?

@caitp
Copy link
Contributor

caitp commented Oct 8, 2014

It would be like 2 lines to add support for both I think, since they're keywords that could be added as constant getters

@Alexsey
Copy link
Contributor Author

Alexsey commented Oct 8, 2014

@caitp Well, I met this when checking devision on zero edge case. Also I prefer to use Infinity instead of something like 10000000 for things that must be the biggest of their kind.

Generally the use of Infinity is a question of taste, and always you could go without it. But it is really confusing when definitely correct code fails.

@btford
Copy link
Contributor

btford commented Oct 8, 2014

Also I prefer to use Infinity instead of something like 10000000

I think better would be to expose a function on scope, so it becomes a question of {{ isLessThanInfinity(someNum) }} versus {{ someNum < Infinity }}

definitely correct code

Reminder that Angular expressions are a subset of JavaScript.

@caitp
Copy link
Contributor

caitp commented Oct 8, 2014

Or even just Number.isFinite(value) which should work even in the expression language (I mean, you aren't going to have a value which is greater than Infinity or less than -Infinity anyways)

@Alexsey
Copy link
Contributor Author

Alexsey commented Oct 8, 2014

Number.isFinite(value) is good. Or even lodash's _.isFinit(value). It suit as well as {{someNum < Infinity}}. I know this now, but if someone else meet same situation he could stuck same way. Because they are nearly equally good.

This should be in the docs, in Angular Expressions vs. JavaScript Expressions section. But does absence of Infinity and NaN is so important to make documentation a little bit harder and explain why they should not be in expressions?

@caitp
Copy link
Contributor

caitp commented Oct 8, 2014

I don't have a strong opinion on this, I mean it would be pretty trivial to add support for Infinity/NaN as constant getters, or we could just document the difference with JS. It's all good

@caitp
Copy link
Contributor

caitp commented Oct 8, 2014

i think we have to draw the line at supporting the void operator though :>

@btford
Copy link
Contributor

btford commented Oct 8, 2014

aw, was really hoping for comma operator and void operator support so i can do: ng-click="doFoo(), void 0"

@Alexsey
Copy link
Contributor Author

Alexsey commented Oct 8, 2014

well... if there where on void in ECMAScript and someone propose to add such in Angular that would definitely fail :)

But it's not about adding void to Angular, it's about removing unnecessary inconsistent with parent spec. So I think void should be added to if there is no reasons for not to adding it.

IMHO comma is a separate topic because its usage considers as 'bad practice' except of cases that may not appear in expressions. As for me user should decide to use it or not, but I'm not as deep in understanding philosophy of Angular to argue about would it supplement with other expressions restrictions or not.

btford added a commit to btford/angular.js that referenced this issue Oct 8, 2014
btford added a commit to btford/angular.js that referenced this issue Oct 9, 2014
btford added a commit to btford/angular.js that referenced this issue Oct 9, 2014
@IgorMinar
Copy link
Contributor

Gut feeling: -1

Keep templates and expressions simple.

On Wed, Oct 8, 2014, 3:26 PM Alexsey [email protected] wrote:

well... if there where on void in ECMAScript and someone propose to add
such in Angular that would definitely fail :)

But it's not about adding void to Angular, it's about removing
unnecessary inconsistent with parent spec. So I think void should be
added to, if there is no reasons for not to adding it.

IMHO comma is a separate topic because its usage considers as 'bad
practice' except of cases that may not appear in expressions. As for me
user should decide to use it or not, but I'm not as deep in understanding
philosophy of Angular to argue about should it be in expressions or not.


Reply to this email directly or view it on GitHub
#9492 (comment).

btford added a commit to btford/angular.js that referenced this issue Oct 9, 2014
btford added a commit to btford/angular.js that referenced this issue Oct 10, 2014
btford added a commit to btford/angular.js that referenced this issue Oct 10, 2014
@Alexsey
Copy link
Contributor Author

Alexsey commented Oct 22, 2014

Should I close this, or you would like to add something else?

@jjlorenzo
Copy link

ng-if="reactor.operationTime === Infinity"

IMHO this is a simple expression, at least more than the hack that works for me:

ng-if="reactor.operationTime === 1/0"

@AlexanderLeonov
Copy link

Will do some necroposting here. :)
Another use case for that would be like this:

<select ui-select2="{ minimumResultsForSearch: Infinity }">

It doesn't make sense for me to add something onto scope for select2 configuration which is that simple - all I want is just hide search box, that's it. Otherwise I'd have to create controller or directive which would place this config on the scope for me, or to make some existing entity to do it. Then if we consider 3-4 such select2's on the page, and 3-4 is not even close to "many"... No, that's definitely overkill. But I'm using angular 1.5.0 and it still doesn't work. :(

@jjlorenzo
Copy link

jjlorenzo commented Mar 4, 2016 via email

@AlexanderLeonov
Copy link

@jjlorenzo Thanks for helping me, I've seen your earlier comment here. It can work of course, but I'm not fond of any kind of hacks if it could be done in a proper way. Also if tomorrow they'll change 1/0 behavior to throw an exception or return zero or whatever else then this code will break. I'm not excited of dealing with such things, so still +1 for implementing explicit support for Infinite

@jjlorenzo
Copy link

jjlorenzo commented Mar 4, 2016 via email

lgalfaso added a commit to lgalfaso/angular.js that referenced this issue Mar 7, 2016
Allow user-defined literals.

Close: angular#9504
Close: angular#9492
lgalfaso added a commit to lgalfaso/angular.js that referenced this issue Mar 7, 2016
Allow user-defined literals.

Close: angular#9504
Close: angular#9492
lgalfaso added a commit to lgalfaso/angular.js that referenced this issue Mar 8, 2016
Allow user-defined literals.

Close: angular#9504
Close: angular#9492
lgalfaso added a commit to lgalfaso/angular.js that referenced this issue Mar 12, 2016
Allow user-defined literals.

Close: angular#9504
Close: angular#9492
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
7 participants