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>>
