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>
