Ok, since I must to continue work on DataGrid, maybe I'll add something like removeStyleProperty as a general utility function since it should be used in more situations and probably will use that for now until a better solution comes along. I guess it could be an option for now...
El mar., 24 dic. 2019 a las 16:31, Harbs (<[email protected]>) escribió: > To me there’s a big difference between -1 and NaN. > > NaN can easily be the result in a bug which results in an unexpected NaN > value. (This has already happened to me.) > Setting something to -1 is a deliberate action. > > -1 is also a common convention for unset or unavailable values (such as > indexOf, etc.). > NaN — not so much and it’s indicative of a bug. > > Anyway, I think everyone would be OK with some kind of function which > unsets the value. > > The question is more how to enable such a thing in the best PAYG way. > > I want to try and brainstorm on that over the next few days. > > > On Dec 23, 2019, at 8:20 PM, Greg Dove <[email protected]> wrote: > > > > Another thing to consider is usage. What is the easiest way to 'unset' > > something like 'size-to-parent' and revert to 'size to content' for > > example, via mxml states, for example. I'm sure there will be ways to > avoid > > it in each case and I'm no fan of using NaN in mxml, but I have seen it > > used in Flex for various layout changes with states in the past. > > > > I'd suggest the 'anti pattern' of using a designated 'invalid' value to > > unset an internal state is not so unusual. We do use it all the time for > > selectedIndex, for example, just in int range instead of number. But that > > same value is returned from the getter. The other 'percentWidth' setter > > implementation I found via searching was also using -1 instead of NaN to > > invalidate/unset vs. positive Double values to 'make active'. > > > > I don't mind either way about this - just adding a couple of > ideas/thoughts > > to make sure we at least consider them. > > > > On Tue, 24 Dec 2019, 06:41 Harbs, <[email protected] <mailto: > [email protected]>> wrote: > > > >> I think we’re getting our wires crossed. ;-) > >> > >> We’re discussing two different things here: > >> > >> 1. How to solve the problem of being able to reset explicit dimensions > of > >> components. > >> 2. Where to put that solution. > >> > >> Solving #1 had two forms that we discussed: > >> a) Using NaN to invalidate dimensions. > >> b) Use functions to reset the values. > >> > >> Solving #2 has the following options: > >> a) Create utility functions to reset the values > >> b) Add the logic to UIBase > >> c) Add the logic to a subclass (such as StyledUIBase) in Basic > >> d) Add the logic to components in other component sets > >> e) Add a bead which takes care of the reseting (somehow). > >> > >> I’m not sure what your position is on all of these points. > >> > >> I feel very strongly that the solution to #1 is “b” and not “a”. > >> > >> Regarding #2, I am okay with any solution other than “b”. > >> > >> Are we on the same page? > >> > >> Thanks, > >> Harbs > >> > >>> On Dec 23, 2019, at 7:14 PM, Carlos Rovira <[email protected]> > >> wrote: > >>> > >>> Hi Harbs, > >>> > >>> El lun., 23 dic. 2019 a las 16:20, Harbs (<[email protected] > >> <mailto:[email protected] <mailto:[email protected]>>>) > escribió: > >>> > >>>> I certainly can’t stop you from implementing things how you’d like in > >>>> Jewel, but I hope you reconsider. > >>>> > >>> > >>> I think it solves a concrete problem that is very useful. For all what > >> you > >>> and Alex said, I understand is not right to put in UIBase, since it > needs > >>> to maintain as agnostic as possible > >>> But since Jewel tries to go straight to the problem, I don't think such > >>> level of abstraction would be what we need in that UI Set that tries to > >> be > >>> flexible in the implementation. > >>> > >>> > >>>> > >>>> I’ll be happy to implement the errors. > >>>> > >>> > >>> Fo me is ok to implement the errors in UIBase. I think the current > >>> implementation needs to go one way or another, but not stay in the > middle > >>> of both. So be free to add it. > >>> > >>> > >>>> > >>>> Is there a reason you don’t like the approach of using a method for > >>>> “inherit” values? That basically would do what you say, but would be > >> more > >>>> explicit about the functionality. I don’t see why using NaN is easier > >> than > >>>> calling a method. Making it explicit gives more type safety which seem > >> like > >>>> a good thing to me. > >>>> > >>> > >>> Both approach are not ideal to me. I think the problem is that UIBase > >> will > >>> reach to all UI sets and visual components (all possible use cases), > >> while > >>> making it only for Jewel, (and to every UI set), will need to, in the > >> case > >>> of Jewel, add to StyledUIBase, and as well to other containers > >> intermediate > >>> classes (three in concrete: Jewel Group, Jewel DataContainerBase and > >> Jewel > >>> Container) to cover all jewel code. So both solutions seems to add > >>> excessive boilerplate code to Royale so not good for me. > >>> > >>> Maybe we need to think how to solve this kind of problems where UIBase > >>> can't hold a piece of code for PAYG or other reasons. > >>> I added StyledUIBase to solve IClassSelectorListSupport problem, that > >> can't > >>> be in UIBase, but maybe StyledUIBase is not a good idea since the code > in > >>> Basic bifurcates and I need to add the exact same code to the three > other > >>> container classes before mentioned. > >>> > >>> If you have some other proposal to solve this kind of problems, I'd > want > >> to > >>> hear it. > >>> > >>> Thanks > >>> > >>> > >>> > >>>> Thanks, > >>>> Harbs > >>>> > >>>>> On Dec 23, 2019, at 5:08 PM, Carlos Rovira <[email protected] > <mailto:[email protected]>> > >>>> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> ok. I think it's clear there's no much consensus, so I think we > should > >>>> left > >>>>> things as they are now and see other ways to solve. > >>>>> I think we can have a removeStyleProperty function that accepts an > >>>> element > >>>>> and a string property to be removed. This can solve most of the > >> problems > >>>> of > >>>>> this kind with any property user needs. > >>>>> As well, I think since Jewel is more focused on making things easier > so > >>>>> I'll implement width/height changes at StyledUIBase level. > >>>>> > >>>>> Thanks for your participation! :) > >>>>> > >>>>> Carlos > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> El lun., 23 dic. 2019 a las 11:42, Harbs (<[email protected] > <mailto:[email protected]>>) > >>>> escribió: > >>>>> > >>>>>> > >>>>>> > >>>>>>> On Dec 23, 2019, at 10:34 AM, Carlos Rovira < > [email protected] <mailto:[email protected]> > >>> > >>>>>> wrote: > >>>>>>> > >>>>>>>>> If NaN is not allowed then what’s the uninitialized value? > >>>>>>>> > >>>>>>>> The initial value is obviously NaN. That has a special meaning on > >> the > >>>>>>>> uninitialized state — meaning there’s no value to set. > >>>>>>>> > >>>>>>> > >>>>>>> For me that't the key: in JS a style not set means it has the > default > >>>>>> value > >>>>>>> since is not assigned to a concrete instance. > >>>>>>> (width and height defaults to auto, position to static, display to > >>>> block > >>>>>> or > >>>>>>> inline depending on the element). > >>>>>> > >>>>>> I disagree. That’s just an implementation detail that doesn’t > concern > >>>> the > >>>>>> user. > >>>>>> > >>>>>> The getter for dimensions never return NaN, so while “_height” might > >> be > >>>>>> NaN, “height” (the getter) will never be NaN. > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> My point is that *setting* the value to NaN is an anti-pattern > >>>> (besides > >>>>>>>> adding extra code for that not being PAYG). Usually setting a > value > >>>>>> which > >>>>>>>> is supposed to be a valid number to NaN indicates a bug somewhere. > >>>> We’d > >>>>>> be > >>>>>>>> doing a better service to developers by explicitly making NaN > >> illegal > >>>>>> and > >>>>>>>> throwing an error rather than allowing it and encouraging an > >>>>>> anti-pattern. > >>>>>>>> > >>>>>>> > >>>>>>> We can do that, but IMO the special way JS works will need people > to > >>>>>> learn > >>>>>>> about what means NaN for width/height in Royale, all because JS > does > >> in > >>>>>>> that strange way, and we need to think "what will be more useful > for > >>>> our > >>>>>>> devs/users?", options are: > >>>>>>> > >>>>>>> - Remove style value for width/height: I think that will be useful > >> for > >>>>>>> them (I know since I work on things like that all the time) > >>>>>> > >>>>>> We should have an inheritWidth and inheritHeight utility function > >> which > >>>>>> removes the style. For non-basic components (such as Jewel), I’d > bake > >>>> this > >>>>>> into the components as a method (with the same name). > >>>>>> > >>>>>> It likely makes sense to have inheritX and inheritY as well. > >>>>>> > >>>>>>> - Make it ilegal (throw error): IMHO, people will find this strange > >>>>>>> since NaN is a possible value for Number, so I think nothing better > >> or > >>>>>>> worse than the above option, but more cumbersome since people will > >>>> left > >>>>>>> without options to go back to the default value in JS. Then some of > >>>>>> them > >>>>>>> could try to do going to lower JS code as I did in some components > >>>>>> already. > >>>>>> > >>>>>> We should do this as well. I don’t think it’s strange at all to get > an > >>>>>> error “height must be a valid number”. It would go a long way > towards > >>>>>> finding bugs. I’ve actually bumped into this class of bugs already. > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Carlos Rovira > >>>>> http://about.me/carlosrovira <http://about.me/carlosrovira> > >>>> > >>>> > >>> > >>> -- > >>> Carlos Rovira > >>> http://about.me/carlosrovira <http://about.me/carlosrovira> < > http://about.me/carlosrovira <http://about.me/carlosrovira>> > > -- Carlos Rovira http://about.me/carlosrovira
