Maybe it’s just me, but the cognitive load of figuring out if the default is actually called if I do
noPreventDefault = false
is much higher than a
applyDefault = false
The first one I have to solve on a piece of paper, the second just clicks. I guess there are other negated parameter and attributes which could be refactored.
Apart from this minor issue: Babylon rocks! Thanks a lot, guys!
Thanks for the feedback!
In general, we don’t change a public variable once it was set, since we support backwards compatibility. Usually (unless we made a mistake) when we use this kind of negation it is because we want to keep the variable optional. Optional means you don’t have to provide it, which also means it will be “undefined” and hence “falsy” in javascript. So we can check if(noPreventDefault) . I agree, this can be a little confusing at first.
Thanks for your quick response.
I see the point of backward compatibility, but are you really planning to never deprecate any part of your API in one major release and then break it in the succeeding one? IMHO, that’s a vital mechanism to keep your API clean and consistent and I would prefer it if your break things (with the deprecation rules described above) compared to a zoo of historically grown warts and inconsistencies in the API.
But I’m not saying that this particular case would justify the whole procedure. 
If my calculations are correct noPreventDefault has the same meaning as applyDefault, so you could have used that. I know there’s a preventDefault for Events which is almost as old as I am. 
The existence of Event.preventDefault() makes noPreventDefault much easier to understand than applyDefault, at least personally for me
Nope, we are not planning to do with. With our existing packages
@Deltakosh will be very happy to read this answer, I am sure, as we had a lot of discussions about this specific subject. Babylon supports backwards compatibility. The more I use other packages, the more I understand why this is very important for developers using your package.
Having said that, when we present a new package, this one can have a different code structure.
About the specific noPreventDefault, I really think it makes sense to keep it this way. Especially since this is exactly what we do - we use preventDefault() if it is set to false. I agree - it might be a little confusing. But we are developers, we love logical thinking!
Ok, I get it. Thanks for the explanations and your work on this awesome project.