Hi, after reading the rest of emails, I think there's a need that others can express about this. So I'll bifurcate this thread to create a new one about "High level abstraction vs specific patterns" as Alex propose. Although my personal opinion is that we are not discussing the same. Hope that thread will give a new reader something short with all the points discussed here in order to give a personal opinion that helps us to know what way to choose.
Thanks! :) Carlos El vie., 20 dic. 2019 a las 5:16, Greg Dove (<[email protected]>) escribió: > What other multitarget SDK's use NaN to unset dimensional Numbers? > > I did not mean this api or NaN as an assigned value specifically, I meant > in general as a solution to the type of problem you mentioned about > incompatible 'native' APIs between targets (assuming I guess that they > can't be overridden and made to behave the same). > Using constants in general is one way to keep meaning in the code and to > abstract from 'different' literal values that provide the same behavior on > different targets. Of course it does mean that if you use literal values, > you would still need to differentiate for each target, so it's by no means > a perfect solution. > > 'Constants don't work so well in MXML. You have to bind to them, or use > the actual literal value.' > It's kind of a side point, but I do have working compiler code locally > (somewhere... I did this some time ago, but never quite got back to finish > it completely) that converts constant bindings to inlined regular startup > value assignments for primitive types (i.e. no longer as constant bindings > for String, Number etc). I do intend to get back to that and add that when > I get a chance (perhaps it should be opt-in). > > ' there has never been an intention to allow application developers to use > NaN as a value set to those properties' > You know that better than I do. I did not work on the original code, and I > presume you did. But that intention was not clear to me from 'looking at > the code' and the logic that already exists in it. I don't mind either way > what actually happens, but I figured I should at least share my thoughts > about what it looked like to me from simply looking at the existing code. > Anyhow, as I said I will leave it to others to continue the discussion. > > > > On Fri, Dec 20, 2019 at 4:19 PM Alex Harui <[email protected]> > wrote: > > > I have not used other frameworks. What other multitarget SDK's use NaN > to > > unset dimensional Numbers? > > > > Constants don't work so well in MXML. You have to bind to them, or use > > the actual literal value. > > > > IMO, while NaN is an allowed value of percentWidth/explicitWidth, there > > has never been an intention to allow application developers to use NaN > as a > > value set to those properties. UIBase does replicate the logic form Flex > > that setting percentWidth sets explicitWidth to NaN and vice versa. > > Supporting NaN as a set value would add more code to UIBase for what is > not > > a mainstream usage. We know we can solve this problem with a utils > > function and that will be more PAYG and less likely to result in > > implementation issues on future runtimes. The utils function would also > > clear explicitWidth as well. > > > > My 2 cents, > > -Alex > > > > On 12/19/19, 6:14 PM, "Greg Dove" <[email protected]> wrote: > > > > ' But the meaning of percentWidth=NaN is not clear. ' > > The way that seems usual in other multitarget sdks in this type of > > situation is to 'abstract' the value being used instead of literal > > NaN. We > > could use a public static const for the 'unset' value and tell > > developers > > to use that. The name of that adds the semantic meaning to the code > as > > well. And it can be set up to cost nothing in release builds because > of > > inlining. > > myComponent.percentWidth = DimensionConsts.PERCENT_VALUE_DISABLED; > > It is more verbose for sure, but much clearer whether it might be -1 > > or NaN > > for a specific target. > > > > I don't think that precludes providing other useful utility functions > > which > > might do different things (like unset size-To-Parent on both > dimensions > > internally) > > > > With the existing code it already assumes that NaN can be an assigned > > value > > for both our current targets. > > So this seems like a bugfix to me, because if NaN is an expected > > possible > > value (and it seems to be because it is already being tested in both > > targets), then setting width style to 'NaN%' is a bug in my view. > > I'm just sharing what looks obvious to me - 'first glance'. So maybe > I > > am > > missing some much deeper interpretation of all this. Anyhow, I will > > leave > > it to others to comment further. > > > > > > On Fri, Dec 20, 2019 at 1:35 PM Alex Harui <[email protected] > > > > wrote: > > > > > IMO, if the application developer is going to be encouraged to set > > > foo.percentWidth=NaN in their code, we might have a hard time > > implementing > > > that on some future runtime that offers a percentWidth API but > > doesn't > > > support NaN. And then the app will not easily migrate to that > future > > > runtime. Flash is a clue. It is a different runtime and doesn't > > support > > > NaN as a value to width. Who knows that some future runtime will > > require? > > > > > > The "meaning" of percentWidth=100 is pretty clear. It means you > want > > > something to stretch the width of its parent. But the meaning of > > > percentWidth=NaN is not clear. That's why I keep focusing on what > > the > > > higher-level objective is, not the browser-specific way you want to > > > accomplish that higher-level objective. I'm pretty sure the > > higher-level > > > objective is to switch a component from being sized to its parent > to > > being > > > sized to its content. Please propose an API with a name that > > describes > > > that objective. Maybe something like > > > org.apache.royale.utils.sizeToContent(child:IUIBase); > > > > > > I'd rather leave the topic of change events to another thread. I'd > > prefer > > > to try to get folks to agree that higher-level abstractions will > > serve > > > Royale better than replicating platform-specific patterns that we > > can't > > > guarantee will work on all platforms and that don't have a clear > > meaning. > > > > > > Thanks, > > > -Alex > > > > > > On 12/19/19, 2:49 PM, "Greg Dove" <[email protected]> wrote: > > > > > > On first glance, that for me that seems an regular bugfix, > > because it > > > looks > > > to be fixing something not working that is intended to actually > > work. > > > > > > I'd also wonder about the inconsistency between the two targets > > for > > > avoiding to dispatch events when the same value is set twice > > (although > > > the > > > 'equals' trap for that will not catch NaNs). > > > It is standard practice elsewhere I think to include this > > avoidance in > > > setters for anything that dispatches 'change' like events (so a > > change > > > is > > > *really* a change). > > > > > > > > > > > > On Fri, Dec 20, 2019 at 11:33 AM Carlos Rovira < > > > [email protected]> > > > wrote: > > > > > > > Hi Alex, > > > > > > > > I think what I want is not what you think I want :) > > > > > > > > "Setting Sprite.width to NaN is not allowed in the Flash > > runtime" > > > > > > > > That will not happen. The actual code for "percentWidth": > > > > > > > > public function set percentWidth(value:Number):void > > > > { > > > > COMPILE::SWF { > > > > if (_percentWidth == value) > > > > return; > > > > if (!isNaN(value)) > > > > _explicitWidth = NaN; > > > > _percentWidth = value; > > > > } > > > > COMPILE::JS { > > > > this._percentWidth = value; > > > > this.positioner.style.width = value.toString() + '%'; > > > > if (!isNaN(value)) > > > > this._explicitWidth = NaN; > > > > } > > > > dispatchEvent(new Event("percentWidthChanged")); > > > > } > > > > > > > > The code I want in percentWidth: > > > > > > > > public function set percentWidth(value:Number):void > > > > { > > > > COMPILE::SWF { > > > > if (_percentWidth == value) > > > > return; > > > > if (!isNaN(value)) > > > > _explicitWidth = NaN; > > > > _percentWidth = value; > > > > } > > > > COMPILE::JS { > > > > this._percentWidth = value; > > > > this.positioner.style.width = isNaN(value) ? null : > > value.toString() > > > + '%'; > > > > if (!isNaN(value)) > > > > this._explicitWidth = NaN; > > > > } > > > > dispatchEvent(new Event("percentWidthChanged")); > > > > } > > > > > > > > Do you see that this is not about the general/global Royale > > API? is > > > just a > > > > fix for JS specific platform. > > > > IOW, is just adding to "COMPILE::JS" the code "isNaN(value) > ? > > null > > > : " > > > > > > > > So we are not baking any "behavior" or "particular semantic" > in > > > Royale > > > > global code. > > > > > > > > Think in what I said in my latest email: "what happens in JS > > if we > > > pass NaN > > > > to percentWidth"? > > > > what value will be in "this.positioner.style.width" at the > end > > of the > > > > method execution? > > > > > > > > Make more sense now? > > > > > > > > Thanks > > > > > > > > Carlos > > > > > > > > > > > > > > > > El jue., 19 dic. 2019 a las 19:57, Alex Harui > > > (<[email protected]>) > > > > escribió: > > > > > > > > > Carlos, > > > > > > > > > > The browser is only one runtime. Setting Sprite.width to > > NaN is > > > not > > > > > allowed in the Flash runtime. What will the next runtime's > > > requirements > > > > be? > > > > > Width as a style is a platform-specific API that, by > > deleting it, > > > AFAICT, > > > > > has the meaning "I want this thing sized to content instead > > of > > > sized to > > > > > parent". IMO, we do not want to bake platform-specific API > > usage > > > into > > > > our > > > > > base classes. > > > > > > > > > > Feel free to make private things protected in UIBase, but > > please > > > do not > > > > > bake platform-specific API usage into Basic. > > > > > > > > > > Thanks, > > > > > -Alex > > > > > > > > > > On 12/19/19, 10:49 AM, "Carlos Rovira" < > > [email protected]> > > > wrote: > > > > > > > > > > Hi Alex, > > > > > > > > > > I can try to add to StyledUIBase instead to UIBase. I > > think > > > I'll need > > > > > to > > > > > make some UIBase vars protected instead of private to > be > > able > > > to do > > > > so > > > > > > > > > > Anyway, I don't think this is "just-in-case" code. Is a > > real > > > value > > > > > width > > > > > can take in Javascript platform. The portability of the > > code > > > is not > > > > > affected this way since is the standard in browsers: > > setting > > > style > > > > > properties to null removes the property in all > browsers. > > If we > > > set > > > > > width to > > > > > NaN in AS3, what does the browser? > > > > > > > > > > I think the problem could be that you're identifying > > this case > > > with a > > > > > particular layout scenario of a concrete component. > It's > > not > > > the > > > > case, > > > > > I > > > > > found this issue other times when working on Royale, > and > > is > > > not about > > > > > to > > > > > make a component to size as the parent or size as its > > content, > > > is > > > > > about to > > > > > allow to assign a value in a concrete property. > > > > > > > > > > I found that need around three times working on > ComboBox, > > > DateField, > > > > > and > > > > > now in DataGrid. I solved hardcoding the style.width in > > that > > > concrete > > > > > code, > > > > > but I think is not the right solution to add code of > > that kind > > > in the > > > > > framework. > > > > > > > > > > The fact other users does not find this problem is > maybe > > that > > > a part > > > > > that > > > > > we are few yet in royale, and people is not going to > > that lower > > > > level, > > > > > is > > > > > that me and you are the only ones working in components > > most > > > of the > > > > > time, > > > > > And between both, maybe I'm doing more styling work > with > > css, > > > layouts > > > > > and > > > > > other kind of visuals. > > > > > > > > > > The solution of adding to StyledUIBase seems to me not > > the > > > right one, > > > > > since > > > > > we end adding lots of code (override all that width and > > height > > > > > methods) for > > > > > something that is just a particular JS case that all > > users of > > > UIBase > > > > > should > > > > > have available, and I'm afraid that some components > that > > are > > > coming > > > > > from > > > > > other basic components (like Group or DataContiner) > will > > not > > > have > > > > that > > > > > properties, and I'll need to add the same code (again) > > to all > > > that > > > > > classes. > > > > > > > > > > I think if we are so strict in this kind of cases, we > > are not > > > using > > > > ok > > > > > PAYG, moreover when as I said before I think we are > > > interpreting PAYG > > > > > not > > > > > right in this concrete case that is just part of the JS > > > platform > > > > still > > > > > not > > > > > considered in Basic implementation. > > > > > > > > > > After this explanation, do you still think I need to > add > > all > > > that > > > > code > > > > > to > > > > > StyledUIBase? Or maybe could it be better to add > > directly to > > > UIBase > > > > > the NaN > > > > > case, so the rest of code in Royale could have this > > missing JS > > > > > implementation? > > > > > > > > > > Thanks! :) > > > > > > > > > > Carlos > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > El jue., 19 dic. 2019 a las 17:34, Alex Harui > > > > > (<[email protected]>) > > > > > escribió: > > > > > > > > > > > IMO, your proposed change adds code "just-in-case" > > someone > > > wants to > > > > > change > > > > > > from sizing-to-parent to sizing-to-content. We've > > written > > > lots of > > > > > > FlexJS/Royale code over the years that works just > fine > > > without that > > > > > > change. That implies to me that this scenario is > not a > > > "standard > > > > > case". > > > > > > > > > > > > If you want to build that in as a standard case to > > Jewel, > > > that's > > > > > fine. > > > > > > Jewel does not have to be as lightweight as Basic. > > > > > > > > > > > > If, over more years, we hear more folks with these > > cases for > > > Basic > > > > > then we > > > > > > can consider adding it to Basic, but I would probably > > just > > > add a > > > > > Utils > > > > > > function like "sizeToContent()" that "does the right > > > thing". In > > > > some > > > > > > component sets, sizing to content might force a > > measuring > > > API to > > > > > run, for > > > > > > example. > > > > > > > > > > > > IMO, it is better to think of the "semantics" or > > "meaning" > > > of some > > > > > code so > > > > > > that we don't bake platform-specific patterns into > the > > > framework. > > > > > We want > > > > > > the framework to be easily portable to other runtimes > > > someday. > > > > > > > > > > > > My 2 cents, > > > > > > -Alex > > > > > > > > > > > > On 12/19/19, 2:47 AM, "Carlos Rovira" < > > > [email protected]> > > > > > wrote: > > > > > > > > > > > > Hi Alex, > > > > > > > > > > > > My perception for this particular case in the JS > > > platform we > > > > are > > > > > > missing a > > > > > > standard case. > > > > > > To try to make a comparison is like if we could > > add to > > > an int > > > > > var any > > > > > > number except "0". > > > > > > > > > > > > IMHO, the PAYG concept does not apply since Basic > > (and > > > any > > > > other > > > > > set) > > > > > > should need in some cases to remove width (so > > browsers > > > apply > > > > the > > > > > > default) > > > > > > and that make JS set "width=null'" to remove it. > > > > > > IOW, we are not translating correctly to JS in > all > > > possible > > > > > cases. > > > > > > > > > > > > In other words we have in UIBase this code: > > > > > > > > > > > > this.positioner.style.width = value.toString() + > > '%'; > > > > > > > > > > > > I tested UIBase with this change worked: > > > > > > > > > > > > this.positioner.style.width = isNaN(value) ? > null : > > > > > value.toString() + > > > > > > 'px'; > > > > > > > > > > > > It's ok to do this change? > > > > > > > > > > > > Thanks > > > > > > > > > > > > Carlos > > > > > > > > > > > > > > > > > > > > > > > > El jue., 19 dic. 2019 a las 3:57, Alex Harui > > > > > (<[email protected] > > > > > > >) > > > > > > escribió: > > > > > > > > > > > > > Basic has the most minimal support for changing > > things. > > > > > Supporting > > > > > > change > > > > > > > takes more code, so because of PAYG, only the > > most > > > expected > > > > > change > > > > > > are > > > > > > > supported. > > > > > > > > > > > > > > What is the "semantics" behind removing > > percentWidth? > > > That > > > > > you want > > > > > > > something to go back to sizing to its content? > > One > > > option is > > > > > that > > > > > > could be > > > > > > > a utils function like > > sizeToContent(widget:IUIBase) > > > that > > > > knows > > > > > how to > > > > > > > manipulate a particular component set's > > widgets. What > > > needs > > > > > to be > > > > > > done to > > > > > > > a component might depend on the component set. > > > > > > > > > > > > > > My 2 cents, > > > > > > > -Alex > > > > > > > > > > > > > > On 12/18/19, 2:32 PM, "Carlos Rovira" < > > > > [email protected] > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I think I had this issue at other time. > > > > > > > > > > > > > > Let's say we have a container where > > percentWidth is > > > > > configured > > > > > > to 100, > > > > > > > so > > > > > > > in html this is: > > > > > > > > > > > > > > <div style="width:100%"/> > > > > > > > > > > > > > > then we need to remove style="width:100%" > so > > we > > > end with: > > > > > > > > > > > > > > <div/> > > > > > > > > > > > > > > In royale we can do > > container.percentWidth=100, but > > > > > there's no > > > > > > way back > > > > > > > right? > > > > > > > we can't do container.percentWidth = NaN or > > > undefined. > > > > > > > > > > > > > > Or I'm missing something? > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Carlos Rovira > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C495907a289f44b5fd9d908d784f2647e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637124048915474335&sdata=NwOqzkTYRBtUczCJdbrat0ns%2FooJQ1kwvZKf7%2FQOt%2Fw%3D&reserved=0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Carlos Rovira > > > > > > > > > > > > > > > > > > > > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C495907a289f44b5fd9d908d784f2647e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637124048915484317&sdata=BSw0%2FIs94ziSfk%2Fe1xm%2BH6loda9pQTzxWtMVEWPOWLY%3D&reserved=0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Carlos Rovira > > > > > > > > > > > > > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C495907a289f44b5fd9d908d784f2647e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637124048915484317&sdata=BSw0%2FIs94ziSfk%2Fe1xm%2BH6loda9pQTzxWtMVEWPOWLY%3D&reserved=0 > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Carlos Rovira > > > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C495907a289f44b5fd9d908d784f2647e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637124048915484317&sdata=BSw0%2FIs94ziSfk%2Fe1xm%2BH6loda9pQTzxWtMVEWPOWLY%3D&reserved=0 > > > > > > > > > > > > > > > > > > > > -- Carlos Rovira http://about.me/carlosrovira
