Hi Harbs,

El lun., 23 dic. 2019 a las 8:19, Harbs (<[email protected]>) 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 <[email protected]>
> 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<mailto:[email protected]>
> > Sent: Sunday, December 22, 2019 7:30 PM
> > To: [email protected]<mailto:[email protected]>
> > 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 <[email protected]> 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 <[email protected]>
> >> 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 (<
> >> [email protected]>)
> >>> 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

Reply via email to