LiveScript

LiveScript copied to clipboard

Why not change the default behavior of this operator to check only owned properties of the object? Or leave the of as is and add Of operator, but logically small letter means reduced object without it's prototype.

My case is similar to this:

someBaseObject = {defaultProp: 0}
a = ^^someBaseObject

if not ('defaultProp' of a)
    a.defaultProp = 2

so I use defaultProp to check later if it's been initialized. I bet that most use cases do not need to check if the property is in prototype.

Interesting. I thought we had of own, but it seems we only have for own

im just encountered, that i never used for own because i never used prototyped objects in the for loop, always plain objects, so had no collisions so far..

An of own (own of?) operator doesn't strike me as an awful idea right now, although it would potentially be a breaking change. I wouldn't want to go with capitalized Of; nothing else in LiveScript is like that. (A more LiveScripty way would be to make an of! operator, I guess, but I'm not crazy about adding another one of those.) Nor would I want to change the semantics of plain of.

Also remember that nothing is stopping you from defining an of-own function yourself and using it with infix syntax: 'defaultProp' `of-own` a.

what about this syntax:

a own 'defaultProp'

to:

a.hasOwnProperty('defaultProp');

Some speed test for in operator vs hasOwnProperty(): https://andrew.hedges.name/experiments/in/

In my browsers Firefox v61, Chrome v64, the function hasOwnProperty always runs faster with 1.000.000 elements. I came to that test debugging performance of my parser (Chrome was highlighting clauses with in operator). Hmm.. I'm thinking about replacing of clause with hasOwnProperty...

Well, yee, i know it's not the main reason for optimization, but, i want to squeeze out the best from JS)

How often do you have a million elements in your lists?

well, i've created 4000 DOM elements and constructed my objects above them using options parser (it took 200ms - inacceptable for smooth interaction with user - for example mouse hover can be very quick and should start as soon as possible). option parser checks if option is present with of operator... maybe i need to modify it somehow... ye, it's not about of, okay.

Why do you need that many dom elements? usually you want "faux scrolling".

It's for testing only. Wanna me drop a link? Sometimes you need to animate several elements at once. For example some rain of particles which follow the mouse move or complex widget which have to perform several transitions on event. Also, sometimes it can't be pre-initialized, as it is created dynamicly. greensock always says that you better always re-create animation, but i dont think it's the best thing.