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]> 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]>>) 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]> > >> 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]>) > >> escribió: > >>> > >>>> > >>>> > >>>>> On Dec 23, 2019, at 10:34 AM, Carlos Rovira <[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 > >> > >> > > > > -- > > Carlos Rovira > > http://about.me/carlosrovira <http://about.me/carlosrovira> >
