You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Carlos Rovira <ca...@apache.org> on 2019/12/20 15:28:14 UTC
[Discuss] Trying to discern between High-level abstraction and
platform specific patterns (was: how to remove style="width:100%" from Royale)
Hi,
this thread is to try to add more people to this discuss this topic with
the essence of the discussion in the other thread. I hope this helps to
decide what should we do, since seems Alex thinks in a way and Greg and I
in another. So please express yourself to try to get a consensus on how to
solve the following dilema:
*PROBLEM: *
"Setting UIBase.width to NaN results in JS platform as 'NaNpx' or 'NaN%'."
In other words we have in UIBase this code:
this.positioner.style.width = value.toString() + '%'; // in COMPILER::JS
and value can be NaN
*PROPOSED SOLUTIONS IN PRECEDENT DISCUSSION: *(since I'm rewording other
thought, please let me know If in some case I'm wrong with it! )
- *Alex:* Thinks about this as Higher level abstraction. Not a bug fix.
Alex thinks we can left UIBase width and height methods untouched, since
NaN is not considered in all platforms. Instead if we need to do specific
pattern then create specific API/definition that rewrites width, height,
percentWidth, percentHeight, setWidth, setHeight. He propose something in
the line of:
org.apache.royale.utils.sizeToContent(child:IUIBase);
- *Greg:* Thinks this is a normal bug since NaN can be set and result is
"NaNpx" or "NaN%". So we are letting users to assign width = NaN, and the
result will made an unwanted result in JS platform due to the code above.
SWF is not affected since SWF does not allow NaN, and we are only fixing a
bug in JS platform.
- *Me: *While I'm in favor of high-level abstraction over platform
specific patterns, sincerely I don't think this problem is about that. As
Greg, I think this is a bug. Moreover, I think we need to address at UIBase
level since is the central point instead to add a new class definition that
rewrites all UIBase methods just to add "isNaN(value) ? null". Basic,
Express, Jewel, MXRoyale, need to address this inconsistency, so don't
think add more definitions that duplicate 99% of the code is the right
solution. All standard browsers accept to assign null to a property to
remove it. So for me NaN (in JS) means "remove the property". I tested a
solution code by this
this.positioner.style.width = isNaN(value) ? null : value.toString() + 'px';
//IN COMPILER::JS
--
Carlos Rovira
http://about.me/carlosrovira
Re: [Discuss] Trying to discern between High-level abstraction and
platform specific patterns (was: how to remove style="width:100%" from
Royale)
Posted by Alex Harui <ah...@adobe.com.INVALID>.
IMO, the subject of this thread is about high-level abstractions vs platform-specific patterns.
"removeStyleProperty" sounds like a platform-specific pattern. I would caution Jewel developers and users against using platform-specific patterns in the APIs, but if that's what you want to promote, that's up to you. (Minor nit, you aren't really removing style.width, you are returning it to its initial value). Nobody will really care until some new platform/runtime comes along. But then again, I'd guess that folks migrating Flex apps are wishing they hadn't used so many platform-specific flash.*.* APIs.
Basic is going to choose least-code higher-level abstractions. By choosing least-code, it should in theory have the least impact on subclasses especially subclasses that are base classes in other component sets. IMO, not supporting NaN as a value is least-code and having separate functions with useful names like sizeWidthToContent() is an appropriate high-level abstraction. But that's just for Basic. We won't dictate that as a rule across all component sets. After all, the MX and Spark emulations will probably have to support NaN for percentWidth/explicitWidth. Jewel can do whatever it wants, although I reserve the right to say "I warned you about that".
There's a separate topic of how to share more code from Basic into the other component sets that's worth discussing in another thread. I'll start that thread shortly.
-Alex
On 12/24/19, 9:15 AM, "Carlos Rovira" <ca...@apache.org> wrote:
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 (<ha...@gmail.com>) 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 <gr...@gmail.com> 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, <harbs.lists@gmail.com <mailto:
> harbs.lists@gmail.com>> 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 <ca...@apache.org>
> >> wrote:
> >>>
> >>> Hi Harbs,
> >>>
> >>> El lun., 23 dic. 2019 a las 16:20, Harbs (<harbs.lists@gmail.com
> >> <mailto:harbs.lists@gmail.com <ma...@gmail.com>>>)
> 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 <carlosrovira@apache.org
> <ma...@apache.org>>
> >>>> 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 (<harbs.lists@gmail.com
> <ma...@gmail.com>>)
> >>>> escribió:
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>> On Dec 23, 2019, at 10:34 AM, Carlos Rovira <
> carlosrovira@apache.org <ma...@apache.org>
> >>>
> >>>>>> 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
> >>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cdf21dfba47034a0b5c9808d78894e2e3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637128045389602203&sdata=HiwAdh9TK0XkETbenEJKSA0OVaRhveUw%2B%2FosX2Yi%2BVM%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cdf21dfba47034a0b5c9808d78894e2e3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637128045389602203&sdata=HiwAdh9TK0XkETbenEJKSA0OVaRhveUw%2B%2FosX2Yi%2BVM%3D&reserved=0>
> >>>>
> >>>>
> >>>
> >>> --
> >>> Carlos Rovira
> >>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cdf21dfba47034a0b5c9808d78894e2e3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637128045389602203&sdata=HiwAdh9TK0XkETbenEJKSA0OVaRhveUw%2B%2FosX2Yi%2BVM%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cdf21dfba47034a0b5c9808d78894e2e3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637128045389602203&sdata=HiwAdh9TK0XkETbenEJKSA0OVaRhveUw%2B%2FosX2Yi%2BVM%3D&reserved=0> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cdf21dfba47034a0b5c9808d78894e2e3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637128045389602203&sdata=HiwAdh9TK0XkETbenEJKSA0OVaRhveUw%2B%2FosX2Yi%2BVM%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cdf21dfba47034a0b5c9808d78894e2e3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637128045389602203&sdata=HiwAdh9TK0XkETbenEJKSA0OVaRhveUw%2B%2FosX2Yi%2BVM%3D&reserved=0>>
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cdf21dfba47034a0b5c9808d78894e2e3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637128045389602203&sdata=HiwAdh9TK0XkETbenEJKSA0OVaRhveUw%2B%2FosX2Yi%2BVM%3D&reserved=0
Re: [Discuss] Trying to discern between High-level abstraction and
platform specific patterns (was: how to remove style="width:100%" from Royale)
Posted by Carlos Rovira <ca...@apache.org>.
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 (<ha...@gmail.com>) 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 <gr...@gmail.com> 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, <harbs.lists@gmail.com <mailto:
> harbs.lists@gmail.com>> 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 <ca...@apache.org>
> >> wrote:
> >>>
> >>> Hi Harbs,
> >>>
> >>> El lun., 23 dic. 2019 a las 16:20, Harbs (<harbs.lists@gmail.com
> >> <mailto:harbs.lists@gmail.com <ma...@gmail.com>>>)
> 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 <carlosrovira@apache.org
> <ma...@apache.org>>
> >>>> 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 (<harbs.lists@gmail.com
> <ma...@gmail.com>>)
> >>>> escribió:
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>> On Dec 23, 2019, at 10:34 AM, Carlos Rovira <
> carlosrovira@apache.org <ma...@apache.org>
> >>>
> >>>>>> 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
Re: [Discuss] Trying to discern between High-level abstraction and
platform specific patterns (was: how to remove style="width:100%" from
Royale)
Posted by Harbs <ha...@gmail.com>.
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 <gr...@gmail.com> 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, <harbs.lists@gmail.com <ma...@gmail.com>> 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 <ca...@apache.org>
>> wrote:
>>>
>>> Hi Harbs,
>>>
>>> El lun., 23 dic. 2019 a las 16:20, Harbs (<harbs.lists@gmail.com
>> <mailto:harbs.lists@gmail.com <ma...@gmail.com>>>) 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 <carlosrovira@apache.org <ma...@apache.org>>
>>>> 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 (<harbs.lists@gmail.com <ma...@gmail.com>>)
>>>> escribió:
>>>>>
>>>>>>
>>>>>>
>>>>>>> On Dec 23, 2019, at 10:34 AM, Carlos Rovira <carlosrovira@apache.org <ma...@apache.org>
>>>
>>>>>> 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>>
Re: [Discuss] Trying to discern between High-level abstraction and
platform specific patterns (was: how to remove style="width:100%" from Royale)
Posted by Carlos Rovira <ca...@apache.org>.
Hi Harbs,
I think Greg exposed more clearly something I want to express in my other
comments. It's clear that using NaN is nothing "orthodox" but
I always thought as an option since we're use to do that in Flex. Probsably
Alex would say that in Flex many "bad practices" was allowed, but
for me in this case is just something "by convention" and as well very
convenient since is "at hand" and I expect all people will need to do.
Anyway, you're right there's a mix of things here. It's clear by me the
paths not allowed. Why I think we need to solve is if we have a better way
to extend UIBase, better than StyledUIBase path, since I'm not very happy
with it.
The worst problem I see is that all we can do in UIBase, other UI sets will
need to add in at least 4 points:
- An UIBase extension
- A Group extension
- A Container extension
- A DataContainerBase extension
It's that right? or do you see other way, less complicated to add new
functionality to a visual element?
I think solving that is what we need to choose a path or another.
Thanks
El lun., 23 dic. 2019 a las 19:20, Greg Dove (<gr...@gmail.com>)
escribió:
> 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, <ha...@gmail.com> 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 <ca...@apache.org>
> > wrote:
> > >
> > > Hi Harbs,
> > >
> > > El lun., 23 dic. 2019 a las 16:20, Harbs (<harbs.lists@gmail.com
> > <ma...@gmail.com>>) 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 <ca...@apache.org>
> > >> 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 (<ha...@gmail.com>)
> > >> escribió:
> > >>>
> > >>>>
> > >>>>
> > >>>>> On Dec 23, 2019, at 10:34 AM, Carlos Rovira <
> carlosrovira@apache.org
> > >
> > >>>> 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>
> >
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: [Discuss] Trying to discern between High-level abstraction and
platform specific patterns (was: how to remove style="width:100%" from Royale)
Posted by Greg Dove <gr...@gmail.com>.
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, <ha...@gmail.com> 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 <ca...@apache.org>
> wrote:
> >
> > Hi Harbs,
> >
> > El lun., 23 dic. 2019 a las 16:20, Harbs (<harbs.lists@gmail.com
> <ma...@gmail.com>>) 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 <ca...@apache.org>
> >> 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 (<ha...@gmail.com>)
> >> escribió:
> >>>
> >>>>
> >>>>
> >>>>> On Dec 23, 2019, at 10:34 AM, Carlos Rovira <carlosrovira@apache.org
> >
> >>>> 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>
>
Re: [Discuss] Trying to discern between High-level abstraction and
platform specific patterns (was: how to remove style="width:100%" from
Royale)
Posted by Harbs <ha...@gmail.com>.
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 <ca...@apache.org> wrote:
>
> Hi Harbs,
>
> El lun., 23 dic. 2019 a las 16:20, Harbs (<harbs.lists@gmail.com <ma...@gmail.com>>) 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 <ca...@apache.org>
>> 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 (<ha...@gmail.com>)
>> escribió:
>>>
>>>>
>>>>
>>>>> On Dec 23, 2019, at 10:34 AM, Carlos Rovira <ca...@apache.org>
>>>> 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>
Re: [Discuss] Trying to discern between High-level abstraction and
platform specific patterns (was: how to remove style="width:100%" from Royale)
Posted by Carlos Rovira <ca...@apache.org>.
Hi Harbs,
El lun., 23 dic. 2019 a las 16:20, Harbs (<ha...@gmail.com>) 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 <ca...@apache.org>
> 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 (<ha...@gmail.com>)
> escribió:
> >
> >>
> >>
> >>> On Dec 23, 2019, at 10:34 AM, Carlos Rovira <ca...@apache.org>
> >> 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
Re: [Discuss] Trying to discern between High-level abstraction and
platform specific patterns (was: how to remove style="width:100%" from
Royale)
Posted by Harbs <ha...@gmail.com>.
I certainly can’t stop you from implementing things how you’d like in Jewel, but I hope you reconsider.
I’ll be happy to implement the errors.
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.
Thanks,
Harbs
> On Dec 23, 2019, at 5:08 PM, Carlos Rovira <ca...@apache.org> 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 (<ha...@gmail.com>) escribió:
>
>>
>>
>>> On Dec 23, 2019, at 10:34 AM, Carlos Rovira <ca...@apache.org>
>> 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
Re: [Discuss] Trying to discern between High-level abstraction and
platform specific patterns (was: how to remove style="width:100%" from Royale)
Posted by Carlos Rovira <ca...@apache.org>.
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 (<ha...@gmail.com>) escribió:
>
>
> > On Dec 23, 2019, at 10:34 AM, Carlos Rovira <ca...@apache.org>
> 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
Re: [Discuss] Trying to discern between High-level abstraction and
platform specific patterns (was: how to remove style="width:100%" from
Royale)
Posted by Harbs <ha...@gmail.com>.
> On Dec 23, 2019, at 10:34 AM, Carlos Rovira <ca...@apache.org> 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.
Re: [Discuss] Trying to discern between High-level abstraction and
platform specific patterns (was: how to remove style="width:100%" from Royale)
Posted by Carlos Rovira <ca...@apache.org>.
Hi Harbs,
El lun., 23 dic. 2019 a las 8:19, Harbs (<ha...@gmail.com>) escribió:
> > 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).
So if you can set royale "width" property to "NaN", be can't neither put
"NaNpx" or "NaN%" nor maintain the previous value, the right decision is to
remove the style so it defaults to "auto". This is a special case for JS
platform due to the special way it's designed, where width is a style and
does not receive a number but a string value that can be like. "auto",
"1px", "100%"
For that reason my proposal is that we should remove the value to match the
initial (default) one on NaN just in JS platform, since SWF and JS are
meaning for width and height are different so, we can deal with them in the
same way.
>
> 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)
- 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.
For me both options are valid, just that first one give us more flexibility
and is more easy to handle for real cases.
>
> Harbs
>
> > On Dec 23, 2019, at 8:45 AM, Yishay Weiss <yi...@hotmail.com>
> wrote:
> >
> > I’m confused: what do you mean “SWF doesn’t allow NaN”. What happens if
> you assign NaN?
> >
> > If NaN is not allowed then what’s the uninitialized value?
> >
> > For PAYG reasons I don’t think UIBase should check for values that will
> reasonably not be set.
> >
> > The code that checks for NaN shouldn’t be duplicated but put in a bead.
> Is that impractical?
> >
> > From: Andrew Wetmore<ma...@gmail.com>
> > Sent: Sunday, December 22, 2019 7:30 PM
> > To: dev@royale.apache.org<ma...@royale.apache.org>
> > Subject: Re: [Discuss] Trying to discern between High-level abstraction
> and platform specific patterns (was: how to remove style="width:100%" from
> Royale)
> >
> > I agree with Harbs that it should not be possible to specify NaN for a
> > dimension. Beyond that, I don't have the technical insights to support a
> > useful opinion.
> >
> > a
> >
> > On Sun, Dec 22, 2019 at 1:19 PM Harbs <ha...@gmail.com> wrote:
> >
> >> Here’s my thoughts:
> >>
> >> I think it should be illegal to specify NaN for dimensions.
> >>
> >> The problem to me seems to be that we should make it obvious to the
> >> developer that there’s an error rather than “fixing” it.
> >>
> >> I would propose adding debug-only code which throws an error if NaN is
> set.
> >>
> >> If the issue is how to remove values completely, that should be a
> utility
> >> function or method.
> >>
> >> My $0.02,
> >> Harbs
> >>
> >>> On Dec 22, 2019, at 4:45 PM, Carlos Rovira <ca...@apache.org>
> >> wrote:
> >>>
> >>> Hi All,
> >>>
> >>> I posted about 48 hours ago, hope other in the community
> >>> (Harbs?Yishay?Josh?Andrew?Piotr?Alina? any other user?...) can express
> >>> something about this in the next 24h so we I can know what way to
> choose.
> >>> Thanks in advance for your help on this!! :)
> >>>
> >>> El vie., 20 dic. 2019 a las 16:28, Carlos Rovira (<
> >> carlosrovira@apache.org>)
> >>> escribió:
> >>>
> >>>> Hi,
> >>>>
> >>>> this thread is to try to add more people to this discuss this topic
> with
> >>>> the essence of the discussion in the other thread. I hope this helps
> to
> >>>> decide what should we do, since seems Alex thinks in a way and Greg
> and
> >> I
> >>>> in another. So please express yourself to try to get a consensus on
> how
> >> to
> >>>> solve the following dilema:
> >>>>
> >>>> *PROBLEM: *
> >>>>
> >>>> "Setting UIBase.width to NaN results in JS platform as 'NaNpx' or
> >> 'NaN%'."
> >>>>
> >>>> In other words we have in UIBase this code:
> >>>>
> >>>> this.positioner.style.width = value.toString() + '%'; // in
> COMPILER::JS
> >>>>
> >>>> and value can be NaN
> >>>>
> >>>> *PROPOSED SOLUTIONS IN PRECEDENT DISCUSSION: *(since I'm rewording
> other
> >>>> thought, please let me know If in some case I'm wrong with it! )
> >>>>
> >>>>
> >>>> - *Alex:* Thinks about this as Higher level abstraction. Not a bug
> >>>> fix. Alex thinks we can left UIBase width and height methods
> >> untouched,
> >>>> since NaN is not considered in all platforms. Instead if we need to
> do
> >>>> specific pattern then create specific API/definition that rewrites
> >>>> width, height, percentWidth, percentHeight, setWidth, setHeight. He
> >>>> propose something in the line of:
> >>>>
> >>>> org.apache.royale.utils.sizeToContent(child:IUIBase);
> >>>>
> >>>> - *Greg:* Thinks this is a normal bug since NaN can be set and result
> >>>> is "NaNpx" or "NaN%". So we are letting users to assign width = NaN,
> >> and
> >>>> the result will made an unwanted result in JS platform due to the
> code
> >>>> above. SWF is not affected since SWF does not allow NaN, and we are
> >> only
> >>>> fixing a bug in JS platform.
> >>>>
> >>>>
> >>>> - *Me: *While I'm in favor of high-level abstraction over platform
> >>>> specific patterns, sincerely I don't think this problem is about
> >> that. As
> >>>> Greg, I think this is a bug. Moreover, I think we need to address at
> >> UIBase
> >>>> level since is the central point instead to add a new class
> >> definition that
> >>>> rewrites all UIBase methods just to add "isNaN(value) ? null". Basic,
> >>>> Express, Jewel, MXRoyale, need to address this inconsistency, so
> don't
> >>>> think add more definitions that duplicate 99% of the code is the
> right
> >>>> solution. All standard browsers accept to assign null to a property
> to
> >>>> remove it. So for me NaN (in JS) means "remove the property". I
> >> tested a
> >>>> solution code by this
> >>>>
> >>>> this.positioner.style.width = isNaN(value) ? null : value.toString() +
> >>>> 'px'; //IN COMPILER::JS
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Carlos Rovira
> >>>> http://about.me/carlosrovira
> >>>>
> >>>>
> >>>
> >>> --
> >>> Carlos Rovira
> >>> http://about.me/carlosrovira
> >>
> >>
> >
> > --
> > Andrew Wetmore
> >
> > http://cottage14.blogspot.com/
> >
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: [Discuss] Trying to discern between High-level abstraction and
platform specific patterns (was: how to remove style="width:100%" from
Royale)
Posted by Harbs <ha...@gmail.com>.
> 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.
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.
Harbs
> On Dec 23, 2019, at 8:45 AM, Yishay Weiss <yi...@hotmail.com> wrote:
>
> I’m confused: what do you mean “SWF doesn’t allow NaN”. What happens if you assign NaN?
>
> If NaN is not allowed then what’s the uninitialized value?
>
> For PAYG reasons I don’t think UIBase should check for values that will reasonably not be set.
>
> The code that checks for NaN shouldn’t be duplicated but put in a bead. Is that impractical?
>
> From: Andrew Wetmore<ma...@gmail.com>
> Sent: Sunday, December 22, 2019 7:30 PM
> To: dev@royale.apache.org<ma...@royale.apache.org>
> Subject: Re: [Discuss] Trying to discern between High-level abstraction and platform specific patterns (was: how to remove style="width:100%" from Royale)
>
> I agree with Harbs that it should not be possible to specify NaN for a
> dimension. Beyond that, I don't have the technical insights to support a
> useful opinion.
>
> a
>
> On Sun, Dec 22, 2019 at 1:19 PM Harbs <ha...@gmail.com> wrote:
>
>> Here’s my thoughts:
>>
>> I think it should be illegal to specify NaN for dimensions.
>>
>> The problem to me seems to be that we should make it obvious to the
>> developer that there’s an error rather than “fixing” it.
>>
>> I would propose adding debug-only code which throws an error if NaN is set.
>>
>> If the issue is how to remove values completely, that should be a utility
>> function or method.
>>
>> My $0.02,
>> Harbs
>>
>>> On Dec 22, 2019, at 4:45 PM, Carlos Rovira <ca...@apache.org>
>> wrote:
>>>
>>> Hi All,
>>>
>>> I posted about 48 hours ago, hope other in the community
>>> (Harbs?Yishay?Josh?Andrew?Piotr?Alina? any other user?...) can express
>>> something about this in the next 24h so we I can know what way to choose.
>>> Thanks in advance for your help on this!! :)
>>>
>>> El vie., 20 dic. 2019 a las 16:28, Carlos Rovira (<
>> carlosrovira@apache.org>)
>>> escribió:
>>>
>>>> Hi,
>>>>
>>>> this thread is to try to add more people to this discuss this topic with
>>>> the essence of the discussion in the other thread. I hope this helps to
>>>> decide what should we do, since seems Alex thinks in a way and Greg and
>> I
>>>> in another. So please express yourself to try to get a consensus on how
>> to
>>>> solve the following dilema:
>>>>
>>>> *PROBLEM: *
>>>>
>>>> "Setting UIBase.width to NaN results in JS platform as 'NaNpx' or
>> 'NaN%'."
>>>>
>>>> In other words we have in UIBase this code:
>>>>
>>>> this.positioner.style.width = value.toString() + '%'; // in COMPILER::JS
>>>>
>>>> and value can be NaN
>>>>
>>>> *PROPOSED SOLUTIONS IN PRECEDENT DISCUSSION: *(since I'm rewording other
>>>> thought, please let me know If in some case I'm wrong with it! )
>>>>
>>>>
>>>> - *Alex:* Thinks about this as Higher level abstraction. Not a bug
>>>> fix. Alex thinks we can left UIBase width and height methods
>> untouched,
>>>> since NaN is not considered in all platforms. Instead if we need to do
>>>> specific pattern then create specific API/definition that rewrites
>>>> width, height, percentWidth, percentHeight, setWidth, setHeight. He
>>>> propose something in the line of:
>>>>
>>>> org.apache.royale.utils.sizeToContent(child:IUIBase);
>>>>
>>>> - *Greg:* Thinks this is a normal bug since NaN can be set and result
>>>> is "NaNpx" or "NaN%". So we are letting users to assign width = NaN,
>> and
>>>> the result will made an unwanted result in JS platform due to the code
>>>> above. SWF is not affected since SWF does not allow NaN, and we are
>> only
>>>> fixing a bug in JS platform.
>>>>
>>>>
>>>> - *Me: *While I'm in favor of high-level abstraction over platform
>>>> specific patterns, sincerely I don't think this problem is about
>> that. As
>>>> Greg, I think this is a bug. Moreover, I think we need to address at
>> UIBase
>>>> level since is the central point instead to add a new class
>> definition that
>>>> rewrites all UIBase methods just to add "isNaN(value) ? null". Basic,
>>>> Express, Jewel, MXRoyale, need to address this inconsistency, so don't
>>>> think add more definitions that duplicate 99% of the code is the right
>>>> solution. All standard browsers accept to assign null to a property to
>>>> remove it. So for me NaN (in JS) means "remove the property". I
>> tested a
>>>> solution code by this
>>>>
>>>> this.positioner.style.width = isNaN(value) ? null : value.toString() +
>>>> 'px'; //IN COMPILER::JS
>>>>
>>>>
>>>>
>>>> --
>>>> Carlos Rovira
>>>> http://about.me/carlosrovira
>>>>
>>>>
>>>
>>> --
>>> Carlos Rovira
>>> http://about.me/carlosrovira
>>
>>
>
> --
> Andrew Wetmore
>
> http://cottage14.blogspot.com/
>
RE: [Discuss] Trying to discern between High-level abstraction and
platform specific patterns (was: how to remove style="width:100%" from
Royale)
Posted by Yishay Weiss <yi...@hotmail.com>.
I’m confused: what do you mean “SWF doesn’t allow NaN”. What happens if you assign NaN?
If NaN is not allowed then what’s the uninitialized value?
For PAYG reasons I don’t think UIBase should check for values that will reasonably not be set.
The code that checks for NaN shouldn’t be duplicated but put in a bead. Is that impractical?
From: Andrew Wetmore<ma...@gmail.com>
Sent: Sunday, December 22, 2019 7:30 PM
To: dev@royale.apache.org<ma...@royale.apache.org>
Subject: Re: [Discuss] Trying to discern between High-level abstraction and platform specific patterns (was: how to remove style="width:100%" from Royale)
I agree with Harbs that it should not be possible to specify NaN for a
dimension. Beyond that, I don't have the technical insights to support a
useful opinion.
a
On Sun, Dec 22, 2019 at 1:19 PM Harbs <ha...@gmail.com> wrote:
> Here’s my thoughts:
>
> I think it should be illegal to specify NaN for dimensions.
>
> The problem to me seems to be that we should make it obvious to the
> developer that there’s an error rather than “fixing” it.
>
> I would propose adding debug-only code which throws an error if NaN is set.
>
> If the issue is how to remove values completely, that should be a utility
> function or method.
>
> My $0.02,
> Harbs
>
> > On Dec 22, 2019, at 4:45 PM, Carlos Rovira <ca...@apache.org>
> wrote:
> >
> > Hi All,
> >
> > I posted about 48 hours ago, hope other in the community
> > (Harbs?Yishay?Josh?Andrew?Piotr?Alina? any other user?...) can express
> > something about this in the next 24h so we I can know what way to choose.
> > Thanks in advance for your help on this!! :)
> >
> > El vie., 20 dic. 2019 a las 16:28, Carlos Rovira (<
> carlosrovira@apache.org>)
> > escribió:
> >
> >> Hi,
> >>
> >> this thread is to try to add more people to this discuss this topic with
> >> the essence of the discussion in the other thread. I hope this helps to
> >> decide what should we do, since seems Alex thinks in a way and Greg and
> I
> >> in another. So please express yourself to try to get a consensus on how
> to
> >> solve the following dilema:
> >>
> >> *PROBLEM: *
> >>
> >> "Setting UIBase.width to NaN results in JS platform as 'NaNpx' or
> 'NaN%'."
> >>
> >> In other words we have in UIBase this code:
> >>
> >> this.positioner.style.width = value.toString() + '%'; // in COMPILER::JS
> >>
> >> and value can be NaN
> >>
> >> *PROPOSED SOLUTIONS IN PRECEDENT DISCUSSION: *(since I'm rewording other
> >> thought, please let me know If in some case I'm wrong with it! )
> >>
> >>
> >> - *Alex:* Thinks about this as Higher level abstraction. Not a bug
> >> fix. Alex thinks we can left UIBase width and height methods
> untouched,
> >> since NaN is not considered in all platforms. Instead if we need to do
> >> specific pattern then create specific API/definition that rewrites
> >> width, height, percentWidth, percentHeight, setWidth, setHeight. He
> >> propose something in the line of:
> >>
> >> org.apache.royale.utils.sizeToContent(child:IUIBase);
> >>
> >> - *Greg:* Thinks this is a normal bug since NaN can be set and result
> >> is "NaNpx" or "NaN%". So we are letting users to assign width = NaN,
> and
> >> the result will made an unwanted result in JS platform due to the code
> >> above. SWF is not affected since SWF does not allow NaN, and we are
> only
> >> fixing a bug in JS platform.
> >>
> >>
> >> - *Me: *While I'm in favor of high-level abstraction over platform
> >> specific patterns, sincerely I don't think this problem is about
> that. As
> >> Greg, I think this is a bug. Moreover, I think we need to address at
> UIBase
> >> level since is the central point instead to add a new class
> definition that
> >> rewrites all UIBase methods just to add "isNaN(value) ? null". Basic,
> >> Express, Jewel, MXRoyale, need to address this inconsistency, so don't
> >> think add more definitions that duplicate 99% of the code is the right
> >> solution. All standard browsers accept to assign null to a property to
> >> remove it. So for me NaN (in JS) means "remove the property". I
> tested a
> >> solution code by this
> >>
> >> this.positioner.style.width = isNaN(value) ? null : value.toString() +
> >> 'px'; //IN COMPILER::JS
> >>
> >>
> >>
> >> --
> >> Carlos Rovira
> >> http://about.me/carlosrovira
> >>
> >>
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
>
>
--
Andrew Wetmore
http://cottage14.blogspot.com/
Re: [Discuss] Trying to discern between High-level abstraction and
platform specific patterns (was: how to remove style="width:100%" from Royale)
Posted by Andrew Wetmore <co...@gmail.com>.
I agree with Harbs that it should not be possible to specify NaN for a
dimension. Beyond that, I don't have the technical insights to support a
useful opinion.
a
On Sun, Dec 22, 2019 at 1:19 PM Harbs <ha...@gmail.com> wrote:
> Here’s my thoughts:
>
> I think it should be illegal to specify NaN for dimensions.
>
> The problem to me seems to be that we should make it obvious to the
> developer that there’s an error rather than “fixing” it.
>
> I would propose adding debug-only code which throws an error if NaN is set.
>
> If the issue is how to remove values completely, that should be a utility
> function or method.
>
> My $0.02,
> Harbs
>
> > On Dec 22, 2019, at 4:45 PM, Carlos Rovira <ca...@apache.org>
> wrote:
> >
> > Hi All,
> >
> > I posted about 48 hours ago, hope other in the community
> > (Harbs?Yishay?Josh?Andrew?Piotr?Alina? any other user?...) can express
> > something about this in the next 24h so we I can know what way to choose.
> > Thanks in advance for your help on this!! :)
> >
> > El vie., 20 dic. 2019 a las 16:28, Carlos Rovira (<
> carlosrovira@apache.org>)
> > escribió:
> >
> >> Hi,
> >>
> >> this thread is to try to add more people to this discuss this topic with
> >> the essence of the discussion in the other thread. I hope this helps to
> >> decide what should we do, since seems Alex thinks in a way and Greg and
> I
> >> in another. So please express yourself to try to get a consensus on how
> to
> >> solve the following dilema:
> >>
> >> *PROBLEM: *
> >>
> >> "Setting UIBase.width to NaN results in JS platform as 'NaNpx' or
> 'NaN%'."
> >>
> >> In other words we have in UIBase this code:
> >>
> >> this.positioner.style.width = value.toString() + '%'; // in COMPILER::JS
> >>
> >> and value can be NaN
> >>
> >> *PROPOSED SOLUTIONS IN PRECEDENT DISCUSSION: *(since I'm rewording other
> >> thought, please let me know If in some case I'm wrong with it! )
> >>
> >>
> >> - *Alex:* Thinks about this as Higher level abstraction. Not a bug
> >> fix. Alex thinks we can left UIBase width and height methods
> untouched,
> >> since NaN is not considered in all platforms. Instead if we need to do
> >> specific pattern then create specific API/definition that rewrites
> >> width, height, percentWidth, percentHeight, setWidth, setHeight. He
> >> propose something in the line of:
> >>
> >> org.apache.royale.utils.sizeToContent(child:IUIBase);
> >>
> >> - *Greg:* Thinks this is a normal bug since NaN can be set and result
> >> is "NaNpx" or "NaN%". So we are letting users to assign width = NaN,
> and
> >> the result will made an unwanted result in JS platform due to the code
> >> above. SWF is not affected since SWF does not allow NaN, and we are
> only
> >> fixing a bug in JS platform.
> >>
> >>
> >> - *Me: *While I'm in favor of high-level abstraction over platform
> >> specific patterns, sincerely I don't think this problem is about
> that. As
> >> Greg, I think this is a bug. Moreover, I think we need to address at
> UIBase
> >> level since is the central point instead to add a new class
> definition that
> >> rewrites all UIBase methods just to add "isNaN(value) ? null". Basic,
> >> Express, Jewel, MXRoyale, need to address this inconsistency, so don't
> >> think add more definitions that duplicate 99% of the code is the right
> >> solution. All standard browsers accept to assign null to a property to
> >> remove it. So for me NaN (in JS) means "remove the property". I
> tested a
> >> solution code by this
> >>
> >> this.positioner.style.width = isNaN(value) ? null : value.toString() +
> >> 'px'; //IN COMPILER::JS
> >>
> >>
> >>
> >> --
> >> Carlos Rovira
> >> http://about.me/carlosrovira
> >>
> >>
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
>
>
--
Andrew Wetmore
http://cottage14.blogspot.com/
Re: [Discuss] Trying to discern between High-level abstraction and
platform specific patterns (was: how to remove style="width:100%" from
Royale)
Posted by Harbs <ha...@gmail.com>.
Here’s my thoughts:
I think it should be illegal to specify NaN for dimensions.
The problem to me seems to be that we should make it obvious to the developer that there’s an error rather than “fixing” it.
I would propose adding debug-only code which throws an error if NaN is set.
If the issue is how to remove values completely, that should be a utility function or method.
My $0.02,
Harbs
> On Dec 22, 2019, at 4:45 PM, Carlos Rovira <ca...@apache.org> wrote:
>
> Hi All,
>
> I posted about 48 hours ago, hope other in the community
> (Harbs?Yishay?Josh?Andrew?Piotr?Alina? any other user?...) can express
> something about this in the next 24h so we I can know what way to choose.
> Thanks in advance for your help on this!! :)
>
> El vie., 20 dic. 2019 a las 16:28, Carlos Rovira (<ca...@apache.org>)
> escribió:
>
>> Hi,
>>
>> this thread is to try to add more people to this discuss this topic with
>> the essence of the discussion in the other thread. I hope this helps to
>> decide what should we do, since seems Alex thinks in a way and Greg and I
>> in another. So please express yourself to try to get a consensus on how to
>> solve the following dilema:
>>
>> *PROBLEM: *
>>
>> "Setting UIBase.width to NaN results in JS platform as 'NaNpx' or 'NaN%'."
>>
>> In other words we have in UIBase this code:
>>
>> this.positioner.style.width = value.toString() + '%'; // in COMPILER::JS
>>
>> and value can be NaN
>>
>> *PROPOSED SOLUTIONS IN PRECEDENT DISCUSSION: *(since I'm rewording other
>> thought, please let me know If in some case I'm wrong with it! )
>>
>>
>> - *Alex:* Thinks about this as Higher level abstraction. Not a bug
>> fix. Alex thinks we can left UIBase width and height methods untouched,
>> since NaN is not considered in all platforms. Instead if we need to do
>> specific pattern then create specific API/definition that rewrites
>> width, height, percentWidth, percentHeight, setWidth, setHeight. He
>> propose something in the line of:
>>
>> org.apache.royale.utils.sizeToContent(child:IUIBase);
>>
>> - *Greg:* Thinks this is a normal bug since NaN can be set and result
>> is "NaNpx" or "NaN%". So we are letting users to assign width = NaN, and
>> the result will made an unwanted result in JS platform due to the code
>> above. SWF is not affected since SWF does not allow NaN, and we are only
>> fixing a bug in JS platform.
>>
>>
>> - *Me: *While I'm in favor of high-level abstraction over platform
>> specific patterns, sincerely I don't think this problem is about that. As
>> Greg, I think this is a bug. Moreover, I think we need to address at UIBase
>> level since is the central point instead to add a new class definition that
>> rewrites all UIBase methods just to add "isNaN(value) ? null". Basic,
>> Express, Jewel, MXRoyale, need to address this inconsistency, so don't
>> think add more definitions that duplicate 99% of the code is the right
>> solution. All standard browsers accept to assign null to a property to
>> remove it. So for me NaN (in JS) means "remove the property". I tested a
>> solution code by this
>>
>> this.positioner.style.width = isNaN(value) ? null : value.toString() +
>> 'px'; //IN COMPILER::JS
>>
>>
>>
>> --
>> Carlos Rovira
>> http://about.me/carlosrovira
>>
>>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
Re: [Discuss] Trying to discern between High-level abstraction and
platform specific patterns (was: how to remove style="width:100%" from Royale)
Posted by Carlos Rovira <ca...@apache.org>.
Hi All,
I posted about 48 hours ago, hope other in the community
(Harbs?Yishay?Josh?Andrew?Piotr?Alina? any other user?...) can express
something about this in the next 24h so we I can know what way to choose.
Thanks in advance for your help on this!! :)
El vie., 20 dic. 2019 a las 16:28, Carlos Rovira (<ca...@apache.org>)
escribió:
> Hi,
>
> this thread is to try to add more people to this discuss this topic with
> the essence of the discussion in the other thread. I hope this helps to
> decide what should we do, since seems Alex thinks in a way and Greg and I
> in another. So please express yourself to try to get a consensus on how to
> solve the following dilema:
>
> *PROBLEM: *
>
> "Setting UIBase.width to NaN results in JS platform as 'NaNpx' or 'NaN%'."
>
> In other words we have in UIBase this code:
>
> this.positioner.style.width = value.toString() + '%'; // in COMPILER::JS
>
> and value can be NaN
>
> *PROPOSED SOLUTIONS IN PRECEDENT DISCUSSION: *(since I'm rewording other
> thought, please let me know If in some case I'm wrong with it! )
>
>
> - *Alex:* Thinks about this as Higher level abstraction. Not a bug
> fix. Alex thinks we can left UIBase width and height methods untouched,
> since NaN is not considered in all platforms. Instead if we need to do
> specific pattern then create specific API/definition that rewrites
> width, height, percentWidth, percentHeight, setWidth, setHeight. He
> propose something in the line of:
>
> org.apache.royale.utils.sizeToContent(child:IUIBase);
>
> - *Greg:* Thinks this is a normal bug since NaN can be set and result
> is "NaNpx" or "NaN%". So we are letting users to assign width = NaN, and
> the result will made an unwanted result in JS platform due to the code
> above. SWF is not affected since SWF does not allow NaN, and we are only
> fixing a bug in JS platform.
>
>
> - *Me: *While I'm in favor of high-level abstraction over platform
> specific patterns, sincerely I don't think this problem is about that. As
> Greg, I think this is a bug. Moreover, I think we need to address at UIBase
> level since is the central point instead to add a new class definition that
> rewrites all UIBase methods just to add "isNaN(value) ? null". Basic,
> Express, Jewel, MXRoyale, need to address this inconsistency, so don't
> think add more definitions that duplicate 99% of the code is the right
> solution. All standard browsers accept to assign null to a property to
> remove it. So for me NaN (in JS) means "remove the property". I tested a
> solution code by this
>
> this.positioner.style.width = isNaN(value) ? null : value.toString() +
> 'px'; //IN COMPILER::JS
>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira