> but no objection if that’s what folks want. My first reaction when it comes to a public, is to offer a consistent, safe and clear API but I'm open to anything too.
Btw, I noticed the package, class and Object.defineProperties comments are not copied to the generated JS, so neither the Apache header, is that an issue ? see: https://gist.github.com/doublefx/20b7949d3b9ff20daaa1 Frédéric THOMAS ---------------------------------------- > From: aha...@adobe.com > To: dev@flex.apache.org > Subject: Re: Re : Re: [FlexJS] Framework using externs (was: Setup Error) > Date: Tue, 11 Aug 2015 13:25:35 +0000 > > > > On 8/11/15, 6:06 AM, "Frédéric THOMAS" <webdoubl...@hotmail.com> wrote: > >>> Makes sense. I was just wondering why a MouseButton class is needed at >>> all and not just a plain String constant. >> >>Maybe is not, but I added, maybe I shouldn't had, isButton(button) => >>boolean which tests to see which button was pressed during the event, the >>type of button is goog.events.BrowserEvent.MouseButton which is declared >>as enum in goog.events.BrowserEvent: >> >>/** >> * Normalized button constants for the mouse. >> * @enum {number} >> */ >>goog.events.BrowserEvent.MouseButton = { >> LEFT: 0, >> MIDDLE: 1, >> RIGHT: 2 >>}; >> >>The closer things I know to match the package and look close to enum is >>the code I shown (well, I could have prevented the constructor to be >>called to be closer). >> >>The other solution would have been to let the developer fill the >>parameter with a uint or a constant but given that's a public API which >>is a wrapper to another public one, it seems to me it should be protected >>against bad values and should match as much as possible the google doc >>found for the wrapped class, I could be wrong to do that way though, that >>what why I asked before to continue this way for other classes which is >>btw more time consuming. > > IMO, it would cause too much code bloat and take too much time to try to > protect inputs against bad values by adding classes like this. In my > vision for FlexJS, we might produce debug-time beads that have extra > checking of uints and strings done at the start of the method. In theory, > if you have tested your code before deploying, the production version > shouldn’t need this checking or extra class definitions. What is more > important to me right now is that we get just enough functionality to > allow customers to produce something useful. Folks did just fine with > current Flex not checking parameters, so I wouldn’t spend too much time on > something like this, but no objection if that’s what folks want. > > -Alex >
