-
Notifications
You must be signed in to change notification settings - Fork 27.4k
Expressions don't understand Infinity #9492
Comments
@IgorMinar @caitp do we want to expose |
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 |
It would be like 2 lines to add support for both I think, since they're keywords that could be added as constant getters |
@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. |
I think better would be to expose a function on scope, so it becomes a question of
Reminder that Angular expressions are a subset of JavaScript. |
Or even just |
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? |
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 |
i think we have to draw the line at supporting the |
aw, was really hoping for comma operator and |
well... if there where on But it's not about adding 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. |
Gut feeling: -1 Keep templates and expressions simple. On Wed, Oct 8, 2014, 3:26 PM Alexsey [email protected] wrote:
|
Should I close this, or you would like to add something else? |
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" |
Will do some necroposting here. :)
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. :( |
I don't know if works for you, but in my case I use a hack: 1/0
<select ui-select2="{ minimumResultsForSearch: 1/0 }">
|
@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 |
I'm totally agree with you, but comming from django world where the
template language are very limited, this design decision is not new for me.
|
Allow user-defined literals. Close: angular#9504 Close: angular#9492
Allow user-defined literals. Close: angular#9504 Close: angular#9492
Allow user-defined literals. Close: angular#9504 Close: angular#9492
Allow user-defined literals. Close: angular#9504 Close: angular#9492
Infinity in expressions is not treating as Infinity number, but as variable
Plunker
So it even can be override
Plunker
The text was updated successfully, but these errors were encountered: