You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Justin Mclean <ju...@classsoftware.com> on 2012/12/19 21:07:29 UTC
Re: svn commit: r1423863 - /incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
HI,
> + var parseFunction:Function = this.parseFunction;
Wouldn't it be better to fix Flacon rather than change the SDK in this way? Seems a bit hackish to me.
Thanks,
Justin
Re: svn commit: r1423863 -
/incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
Posted by Alex Harui <ah...@adobe.com>.
Ok. I didn't see that.
On 12/19/12 2:45 PM, "Chema Balsas" <jb...@gmail.com> wrote:
>>
>> I don't think that's the right change. I'm guessing the intent is to
>> change
>> a local variable, not the instance's height property?
>
>
> I think height was already a local variable as it was being passed as an
> argument to the call
>
> override protected function drawRowBackground(s:Sprite, rowIndex:int,
>> y:Number, height:Number,
>> color:uint, dataIndex:int):void
>
>
> 2012/12/19 Alex Harui <ah...@adobe.com>
>
>>
>>
>>
>> On 12/19/12 2:23 PM, "Chema Balsas" <jb...@gmail.com> wrote:
>>
>>>>
>>>> But but what about this
>>>> Was:
>>>> var height:Number = Math.min(height,
>>>> listContent.height -
>>>> y);
>>>> changed to:
>>>> height = Math.min(height, listContent.height - y);
>> Hi Chema,
>>
>> I don't think that's the right change. I'm guessing the intent is to
>> change
>> a local variable, not the instance's height property?
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: svn commit: r1423863 - /incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
Posted by Chema Balsas <jb...@gmail.com>.
>
> I don't think that's the right change. I'm guessing the intent is to
> change
> a local variable, not the instance's height property?
I think height was already a local variable as it was being passed as an
argument to the call
override protected function drawRowBackground(s:Sprite, rowIndex:int,
> y:Number, height:Number,
> color:uint, dataIndex:int):void
2012/12/19 Alex Harui <ah...@adobe.com>
>
>
>
> On 12/19/12 2:23 PM, "Chema Balsas" <jb...@gmail.com> wrote:
>
> >>
> >> But but what about this
> >> Was:
> >> var height:Number = Math.min(height,
> >> listContent.height -
> >> y);
> >> changed to:
> >> height = Math.min(height, listContent.height - y);
> Hi Chema,
>
> I don't think that's the right change. I'm guessing the intent is to
> change
> a local variable, not the instance's height property?
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
Re: svn commit: r1423863 - /incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Sorry for all the noise...
No need to be sorry any commit is only a revert away. The fact that this is all public mean we're likely to catch any issues earlier than later - all part of the process.
Justin
Re: svn commit: r1423863 - /incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
Posted by Chema Balsas <jb...@gmail.com>.
Ok then... both commits have been reverted and the issues I originally
created for them have been reopened.
As Alex suggested, I'll be working on creating simple tests and log
particular jira issues for the bugs we've found.
Sorry for all the noise...
Cheers,
Chema
2012/12/20 Chema Balsas <jb...@gmail.com>
> Since this is old code without a lot of tests behind in, in this case the
>> best practice would be to touch as little code as possible.
>
>
> I agree... I did ran a full mustella pass though, to be sure, before
> committing. I assume not even that is enough then, and that some parts of
> code may be uncovered, right?
>
> 2012/12/19 Carol Frampton <cf...@adobe.com>
>
>>
>>
>> On 12/19/12 5 :40PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>>
>> >Hi,
>> >
>> >> I don't think that's the right change. I'm guessing the intent is to
>> >>change
>> >> a local variable, not the instance's height property?
>> >
>> >
>> >Nice catch. Calling a variable the same as a local property is probably a
>> >bad idea. Best fix here I think would be to rename height to something
>> >else?
>>
>>
>> Since this is old code without a lot of tests behind in, in this case the
>> best practice would be to touch as little code as possible.
>>
>> Carol
>>
>>
>
Re: svn commit: r1423863 -
/incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
Posted by Alex Harui <ah...@adobe.com>.
On 12/19/12 3:02 PM, "Chema Balsas" <jb...@gmail.com> wrote:
>>
>> Since this is old code without a lot of tests behind in, in this case the
>> best practice would be to touch as little code as possible.
>
>
> I agree... I did ran a full mustella pass though, to be sure, before
> committing. I assume not even that is enough then, and that some parts of
> code may be uncovered, right?
That reminds me to try to integrate a coverage tool into mustella someday.
I was told we had pretty good coverage, but for sure, we don't have enough
test cases otherwise we'd have fewer open bugs.
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: svn commit: r1423863 - /incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
Posted by Chema Balsas <jb...@gmail.com>.
>
> Since this is old code without a lot of tests behind in, in this case the
> best practice would be to touch as little code as possible.
I agree... I did ran a full mustella pass though, to be sure, before
committing. I assume not even that is enough then, and that some parts of
code may be uncovered, right?
2012/12/19 Carol Frampton <cf...@adobe.com>
>
>
> On 12/19/12 5 :40PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>
> >Hi,
> >
> >> I don't think that's the right change. I'm guessing the intent is to
> >>change
> >> a local variable, not the instance's height property?
> >
> >
> >Nice catch. Calling a variable the same as a local property is probably a
> >bad idea. Best fix here I think would be to rename height to something
> >else?
>
>
> Since this is old code without a lot of tests behind in, in this case the
> best practice would be to touch as little code as possible.
>
> Carol
>
>
Re: svn commit: r1423863 -
/incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
Posted by Carol Frampton <cf...@adobe.com>.
On 12/19/12 5 :40PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>> I don't think that's the right change. I'm guessing the intent is to
>>change
>> a local variable, not the instance's height property?
>
>
>Nice catch. Calling a variable the same as a local property is probably a
>bad idea. Best fix here I think would be to rename height to something
>else?
Since this is old code without a lot of tests behind in, in this case the
best practice would be to touch as little code as possible.
Carol
Re: svn commit: r1423863 -
/incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
Posted by Alex Harui <ah...@adobe.com>.
On 12/19/12 2:40 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
>> I don't think that's the right change. I'm guessing the intent is to change
>> a local variable, not the instance's height property?
>
>
> Nice catch. Calling a variable the same as a local property is probably a bad
> idea. Best fix here I think would be to rename height to something else?
It isn't my favorite practice, but it shouldn't cause a compiler error or
warning. It would be great if Chema could put together a simple test case
or unit test for this scenario. We do frequently mask instance properties
with constructor arguments although that isn't quite the same thing here.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: svn commit: r1423863 - /incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I don't think that's the right change. I'm guessing the intent is to change
> a local variable, not the instance's height property?
Nice catch. Calling a variable the same as a local property is probably a bad idea. Best fix here I think would be to rename height to something else?
Justin
Re: svn commit: r1423863 -
/incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
Posted by Alex Harui <ah...@adobe.com>.
On 12/19/12 2:23 PM, "Chema Balsas" <jb...@gmail.com> wrote:
>>
>> But but what about this
>> Was:
>> var height:Number = Math.min(height,
>> listContent.height -
>> y);
>> changed to:
>> height = Math.min(height, listContent.height - y);
Hi Chema,
I don't think that's the right change. I'm guessing the intent is to change
a local variable, not the instance's height property?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: svn commit: r1423863 - /incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
Posted by Chema Balsas <jb...@gmail.com>.
>
> But but what about this
> Was:
> var height:Number = Math.min(height,
> listContent.height -
> y);
> changed to:
> height = Math.min(height, listContent.height - y);
Oh, sorry, that would be me. The problem there was of the 'duplicated
variable' type. It was me who put it alltogether in one line while fixing
the rest :S
2012/12/19 Carol Frampton <cf...@adobe.com>
>
>
> On 12/19/12 5 :06PM, "Chema Balsas" <jb...@gmail.com> wrote:
>
> >>
> >> The policy should be to not change valid and correct AS code in the SDK
> >> just
> >> because Falcon cannot compile it. There will be times when we will
> >>change
> >> the SDK code because Falcon is stricter than MXMLC, but I don't think
> >>these
> >> changes fall into that category.
> >
> >
> >I've already left some issues waiting for Gordon to comment on wether
> >they're Falcon bugs or not. I may have misjugded these. As I saw similar
> >code in place I assumed it was a safe change. I'll be reverting them soon.
> >Is it okay to wait to see if Gordon can confirm this as a Falcon bug, or
> >do
> >you prefer it to be reverted right away and then brought in later if not?
>
> Reverts are a pain in the neck so I'm fine with waiting for Gordon.
>
>
> But but what about this
>
> Was:
>
> var height:Number = Math.min(height,
> listContent.height -
> y);
>
> changed to:
>
> height = Math.min(height, listContent.height - y);
>
>
>
> It seems to me the compiler should be able to handle all whitespace.
>
> Carol
>
>
>
> >
> >Sorry for the inconvenience everyone.
> >
> >Cheers,
> >Chema
> >
> >2012/12/19 Chema Balsas <jb...@gmail.com>
> >
> >> What was the type of d, the type of v, and the type of parseFunction?
> >>
> >>
> >> d was Date, v was object, and for parseFunction there was
> >>
> >> override public function set parseFunction(value:Function):void
> >> {
> >> super.parseFunction = value;
> >> }
> >>
> >>
> >> What is the type of newStyles? Is styleFunction of type Function?
> >>
> >>
> >> The same case... newStyles is Object, for styleFunction there is
> >>
> >> override public function set styleFunction(value:Function):void
> >> {
> >> super.styleFunction = value;
> >> }
> >>
> >>
> >> 2012/12/19 Gordon Smith <go...@adobe.com>
> >>
> >>> What is the type of newStyles? Is styleFunction of type Function?
> >>>
> >>> - Gordon
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: Chema Balsas [mailto:jbalsas@gmail.com]
> >>> Sent: Wednesday, December 19, 2012 12:47 PM
> >>> To: flex-dev@incubator.apache.org
> >>> Subject: Re: svn commit: r1423863 -
> >>>
> >>>/incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/c
> >>>harts/DateTimeAxis.as
> >>>
> >>> The error in OLAPDatagrid.as was
> >>>
> >>> Error: Implicit coercion of a value of type IOLAPAxisPosition to an
> >>> > unrelated type Function.
> >>> > newStyles = styleFunction(rowPosn, colPosn, cellValue);
> >>> > ^
> >>>
> >>>
> >>> Both may be related with a setter with that name being defined in the
> >>> same class.
> >>>
> >>> @Gordon is this something you'll be taking care of inside Falcon? I'll
> >>> revert these two, in that case...
> >>>
> >>> Cheers,
> >>> Chema
> >>>
> >>> 2012/12/19 Carol Frampton <cf...@adobe.com>
> >>>
> >>> > svn commit: r1423864 looks like it falls in the same category and
> >>> > should be reverted
> >>> >
> >>> > Carol
> >>> >
> >>> >
> >>> >
> >>> > On 12/19/12 3 :07PM, "Justin Mclean" <ju...@classsoftware.com>
> >>>wrote:
> >>> >
> >>> > >HI,
> >>> > >
> >>> > >> + var parseFunction:Function = this.parseFunction;
> >>> > >
> >>> > >
> >>> > >Wouldn't it be better to fix Flacon rather than change the SDK in
> >>> > >this way? Seems a bit hackish to me.
> >>> > >
> >>> > >Thanks,
> >>> > >Justin
> >>> > >
> >>> >
> >>> >
> >>>
> >>
> >>
>
>
Re: svn commit: r1423863 - /incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> var height:Number = Math.min(height,
> listContent.height -
> y);
> changed to:
> height = Math.min(height, listContent.height - y);
The new version is also much easier to read IMO.
Justin
Re: svn commit: r1423863 -
/incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
Posted by Alex Harui <ah...@adobe.com>.
On 12/19/12 2:18 PM, "Carol Frampton" <cf...@adobe.com> wrote:
>
>
> On 12/19/12 5 :06PM, "Chema Balsas" <jb...@gmail.com> wrote:
>
>>>
>>> The policy should be to not change valid and correct AS code in the SDK
>>> just
>>> because Falcon cannot compile it. There will be times when we will
>>> change
>>> the SDK code because Falcon is stricter than MXMLC, but I don't think
>>> these
>>> changes fall into that category.
>>
>>
>> I've already left some issues waiting for Gordon to comment on wether
>> they're Falcon bugs or not. I may have misjugded these. As I saw similar
>> code in place I assumed it was a safe change. I'll be reverting them soon.
>> Is it okay to wait to see if Gordon can confirm this as a Falcon bug, or
>> do
>> you prefer it to be reverted right away and then brought in later if not?
>
> Reverts are a pain in the neck so I'm fine with waiting for Gordon.
>
Chema, if you truly believe the language should not support the constructs
that are causing the problem, then you can wait for Gordon. But IMO, the
change you made in this checkin works around a bug in Falcon. It would be
better if you would create a JIRA ticket with a simpler test case. I think
the issue for DateTimeAxis and OLAPDG is that it overrides the setter but
not the getter and the code is trying to access the getter. I'm pretty sure
it is ok to override just the setter and not the getter.
In the other checkin, Falcon should not have issues with
whitespace/linebreaks so those lines should be valid. Again, filing JIRA
tickets with simple test cases or creating unit tests would be better.
Also, it may cause a bug to not use super.maxHorizontalScrollPosition in
AdvancedDataGrid.as. Falcon should not fail to compile super.someProperty
unless that propert is not defined on the ancestors.
If statements with assignments in subexpressions should still work. Please
file a JIRA ticket with a simple test case.
The only changes I saw that looked valid was the two changes to prevent
duplicate local property declaration.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: svn commit: r1423863 -
/incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
Posted by Carol Frampton <cf...@adobe.com>.
On 12/19/12 5 :06PM, "Chema Balsas" <jb...@gmail.com> wrote:
>>
>> The policy should be to not change valid and correct AS code in the SDK
>> just
>> because Falcon cannot compile it. There will be times when we will
>>change
>> the SDK code because Falcon is stricter than MXMLC, but I don't think
>>these
>> changes fall into that category.
>
>
>I've already left some issues waiting for Gordon to comment on wether
>they're Falcon bugs or not. I may have misjugded these. As I saw similar
>code in place I assumed it was a safe change. I'll be reverting them soon.
>Is it okay to wait to see if Gordon can confirm this as a Falcon bug, or
>do
>you prefer it to be reverted right away and then brought in later if not?
Reverts are a pain in the neck so I'm fine with waiting for Gordon.
But but what about this
Was:
var height:Number = Math.min(height,
listContent.height -
y);
changed to:
height = Math.min(height, listContent.height - y);
It seems to me the compiler should be able to handle all whitespace.
Carol
>
>Sorry for the inconvenience everyone.
>
>Cheers,
>Chema
>
>2012/12/19 Chema Balsas <jb...@gmail.com>
>
>> What was the type of d, the type of v, and the type of parseFunction?
>>
>>
>> d was Date, v was object, and for parseFunction there was
>>
>> override public function set parseFunction(value:Function):void
>> {
>> super.parseFunction = value;
>> }
>>
>>
>> What is the type of newStyles? Is styleFunction of type Function?
>>
>>
>> The same case... newStyles is Object, for styleFunction there is
>>
>> override public function set styleFunction(value:Function):void
>> {
>> super.styleFunction = value;
>> }
>>
>>
>> 2012/12/19 Gordon Smith <go...@adobe.com>
>>
>>> What is the type of newStyles? Is styleFunction of type Function?
>>>
>>> - Gordon
>>>
>>>
>>> -----Original Message-----
>>> From: Chema Balsas [mailto:jbalsas@gmail.com]
>>> Sent: Wednesday, December 19, 2012 12:47 PM
>>> To: flex-dev@incubator.apache.org
>>> Subject: Re: svn commit: r1423863 -
>>>
>>>/incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/c
>>>harts/DateTimeAxis.as
>>>
>>> The error in OLAPDatagrid.as was
>>>
>>> Error: Implicit coercion of a value of type IOLAPAxisPosition to an
>>> > unrelated type Function.
>>> > newStyles = styleFunction(rowPosn, colPosn, cellValue);
>>> > ^
>>>
>>>
>>> Both may be related with a setter with that name being defined in the
>>> same class.
>>>
>>> @Gordon is this something you'll be taking care of inside Falcon? I'll
>>> revert these two, in that case...
>>>
>>> Cheers,
>>> Chema
>>>
>>> 2012/12/19 Carol Frampton <cf...@adobe.com>
>>>
>>> > svn commit: r1423864 looks like it falls in the same category and
>>> > should be reverted
>>> >
>>> > Carol
>>> >
>>> >
>>> >
>>> > On 12/19/12 3 :07PM, "Justin Mclean" <ju...@classsoftware.com>
>>>wrote:
>>> >
>>> > >HI,
>>> > >
>>> > >> + var parseFunction:Function = this.parseFunction;
>>> > >
>>> > >
>>> > >Wouldn't it be better to fix Flacon rather than change the SDK in
>>> > >this way? Seems a bit hackish to me.
>>> > >
>>> > >Thanks,
>>> > >Justin
>>> > >
>>> >
>>> >
>>>
>>
>>
Re: svn commit: r1423863 - /incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
Posted by Chema Balsas <jb...@gmail.com>.
>
> The policy should be to not change valid and correct AS code in the SDK
> just
> because Falcon cannot compile it. There will be times when we will change
> the SDK code because Falcon is stricter than MXMLC, but I don't think these
> changes fall into that category.
I've already left some issues waiting for Gordon to comment on wether
they're Falcon bugs or not. I may have misjugded these. As I saw similar
code in place I assumed it was a safe change. I'll be reverting them soon.
Is it okay to wait to see if Gordon can confirm this as a Falcon bug, or do
you prefer it to be reverted right away and then brought in later if not?
Sorry for the inconvenience everyone.
Cheers,
Chema
2012/12/19 Chema Balsas <jb...@gmail.com>
> What was the type of d, the type of v, and the type of parseFunction?
>
>
> d was Date, v was object, and for parseFunction there was
>
> override public function set parseFunction(value:Function):void
> {
> super.parseFunction = value;
> }
>
>
> What is the type of newStyles? Is styleFunction of type Function?
>
>
> The same case... newStyles is Object, for styleFunction there is
>
> override public function set styleFunction(value:Function):void
> {
> super.styleFunction = value;
> }
>
>
> 2012/12/19 Gordon Smith <go...@adobe.com>
>
>> What is the type of newStyles? Is styleFunction of type Function?
>>
>> - Gordon
>>
>>
>> -----Original Message-----
>> From: Chema Balsas [mailto:jbalsas@gmail.com]
>> Sent: Wednesday, December 19, 2012 12:47 PM
>> To: flex-dev@incubator.apache.org
>> Subject: Re: svn commit: r1423863 -
>> /incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
>>
>> The error in OLAPDatagrid.as was
>>
>> Error: Implicit coercion of a value of type IOLAPAxisPosition to an
>> > unrelated type Function.
>> > newStyles = styleFunction(rowPosn, colPosn, cellValue);
>> > ^
>>
>>
>> Both may be related with a setter with that name being defined in the
>> same class.
>>
>> @Gordon is this something you'll be taking care of inside Falcon? I'll
>> revert these two, in that case...
>>
>> Cheers,
>> Chema
>>
>> 2012/12/19 Carol Frampton <cf...@adobe.com>
>>
>> > svn commit: r1423864 looks like it falls in the same category and
>> > should be reverted
>> >
>> > Carol
>> >
>> >
>> >
>> > On 12/19/12 3 :07PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>> >
>> > >HI,
>> > >
>> > >> + var parseFunction:Function = this.parseFunction;
>> > >
>> > >
>> > >Wouldn't it be better to fix Flacon rather than change the SDK in
>> > >this way? Seems a bit hackish to me.
>> > >
>> > >Thanks,
>> > >Justin
>> > >
>> >
>> >
>>
>
>
Re: svn commit: r1423863 - /incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
Posted by Chema Balsas <jb...@gmail.com>.
>
> Just try to keep it in the same style as the current code in general, but
> it does vary a little and there are inconsistencies.
Thanks! Will do
2012/12/19 Justin Mclean <ju...@classsoftware.com>
> Hi,
>
> > BTW, in regard of the whitespace/new lines... do we have a coding style
> > document in the wiki to follow?
>
> Just try to keep it in the same style as the current code in general, but
> it does vary a little and there are inconsistencies.
>
> Thanks,
> Justin
Re: svn commit: r1423863 - /incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> BTW, in regard of the whitespace/new lines... do we have a coding style
> document in the wiki to follow?
Just try to keep it in the same style as the current code in general, but it does vary a little and there are inconsistencies.
Thanks,
Justin
Re: svn commit: r1423863 - /incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
Posted by Chema Balsas <jb...@gmail.com>.
Ok, I'll be reverting them shortly, and definitely being more careful in
the future...
BTW, in regard of the whitespace/new lines... do we have a coding style
document in the wiki to follow?
Sorry again for the trouble.
Cheers,
Chema
2012/12/19 Gordon Smith <go...@adobe.com>
> I think these are Falcon bugs.
>
> - Gordon
>
> -----Original Message-----
> From: Chema Balsas [mailto:jbalsas@gmail.com]
> Sent: Wednesday, December 19, 2012 1:57 PM
> To: flex-dev@incubator.apache.org
> Subject: Re: svn commit: r1423863 -
> /incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
>
> >
> > What was the type of d, the type of v, and the type of parseFunction?
>
>
> d was Date, v was object, and for parseFunction there was
>
> override public function set parseFunction(value:Function):void
> {
> super.parseFunction = value;
> }
>
>
> What is the type of newStyles? Is styleFunction of type Function?
>
>
> The same case... newStyles is Object, for styleFunction there is
>
> override public function set styleFunction(value:Function):void
> {
> super.styleFunction = value;
> }
>
>
> 2012/12/19 Gordon Smith <go...@adobe.com>
>
> > What is the type of newStyles? Is styleFunction of type Function?
> >
> > - Gordon
> >
> >
> > -----Original Message-----
> > From: Chema Balsas [mailto:jbalsas@gmail.com]
> > Sent: Wednesday, December 19, 2012 12:47 PM
> > To: flex-dev@incubator.apache.org
> > Subject: Re: svn commit: r1423863 -
> > /incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx
> > /charts/DateTimeAxis.as
> >
> > The error in OLAPDatagrid.as was
> >
> > Error: Implicit coercion of a value of type IOLAPAxisPosition to an
> > > unrelated type Function.
> > > newStyles = styleFunction(rowPosn, colPosn, cellValue);
> > > ^
> >
> >
> > Both may be related with a setter with that name being defined in the
> > same class.
> >
> > @Gordon is this something you'll be taking care of inside Falcon? I'll
> > revert these two, in that case...
> >
> > Cheers,
> > Chema
> >
> > 2012/12/19 Carol Frampton <cf...@adobe.com>
> >
> > > svn commit: r1423864 looks like it falls in the same category and
> > > should be reverted
> > >
> > > Carol
> > >
> > >
> > >
> > > On 12/19/12 3 :07PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> > >
> > > >HI,
> > > >
> > > >> + var parseFunction:Function = this.parseFunction;
> > > >
> > > >
> > > >Wouldn't it be better to fix Flacon rather than change the SDK in
> > > >this way? Seems a bit hackish to me.
> > > >
> > > >Thanks,
> > > >Justin
> > > >
> > >
> > >
> >
>
RE: svn commit: r1423863 -
/incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
Posted by Gordon Smith <go...@adobe.com>.
I think these are Falcon bugs.
- Gordon
-----Original Message-----
From: Chema Balsas [mailto:jbalsas@gmail.com]
Sent: Wednesday, December 19, 2012 1:57 PM
To: flex-dev@incubator.apache.org
Subject: Re: svn commit: r1423863 - /incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
>
> What was the type of d, the type of v, and the type of parseFunction?
d was Date, v was object, and for parseFunction there was
override public function set parseFunction(value:Function):void
{
super.parseFunction = value;
}
What is the type of newStyles? Is styleFunction of type Function?
The same case... newStyles is Object, for styleFunction there is
override public function set styleFunction(value:Function):void
{
super.styleFunction = value;
}
2012/12/19 Gordon Smith <go...@adobe.com>
> What is the type of newStyles? Is styleFunction of type Function?
>
> - Gordon
>
>
> -----Original Message-----
> From: Chema Balsas [mailto:jbalsas@gmail.com]
> Sent: Wednesday, December 19, 2012 12:47 PM
> To: flex-dev@incubator.apache.org
> Subject: Re: svn commit: r1423863 -
> /incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx
> /charts/DateTimeAxis.as
>
> The error in OLAPDatagrid.as was
>
> Error: Implicit coercion of a value of type IOLAPAxisPosition to an
> > unrelated type Function.
> > newStyles = styleFunction(rowPosn, colPosn, cellValue);
> > ^
>
>
> Both may be related with a setter with that name being defined in the
> same class.
>
> @Gordon is this something you'll be taking care of inside Falcon? I'll
> revert these two, in that case...
>
> Cheers,
> Chema
>
> 2012/12/19 Carol Frampton <cf...@adobe.com>
>
> > svn commit: r1423864 looks like it falls in the same category and
> > should be reverted
> >
> > Carol
> >
> >
> >
> > On 12/19/12 3 :07PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> >
> > >HI,
> > >
> > >> + var parseFunction:Function = this.parseFunction;
> > >
> > >
> > >Wouldn't it be better to fix Flacon rather than change the SDK in
> > >this way? Seems a bit hackish to me.
> > >
> > >Thanks,
> > >Justin
> > >
> >
> >
>
Re: svn commit: r1423863 - /incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
Posted by Chema Balsas <jb...@gmail.com>.
>
> What was the type of d, the type of v, and the type of parseFunction?
d was Date, v was object, and for parseFunction there was
override public function set parseFunction(value:Function):void
{
super.parseFunction = value;
}
What is the type of newStyles? Is styleFunction of type Function?
The same case... newStyles is Object, for styleFunction there is
override public function set styleFunction(value:Function):void
{
super.styleFunction = value;
}
2012/12/19 Gordon Smith <go...@adobe.com>
> What is the type of newStyles? Is styleFunction of type Function?
>
> - Gordon
>
>
> -----Original Message-----
> From: Chema Balsas [mailto:jbalsas@gmail.com]
> Sent: Wednesday, December 19, 2012 12:47 PM
> To: flex-dev@incubator.apache.org
> Subject: Re: svn commit: r1423863 -
> /incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
>
> The error in OLAPDatagrid.as was
>
> Error: Implicit coercion of a value of type IOLAPAxisPosition to an
> > unrelated type Function.
> > newStyles = styleFunction(rowPosn, colPosn, cellValue);
> > ^
>
>
> Both may be related with a setter with that name being defined in the same
> class.
>
> @Gordon is this something you'll be taking care of inside Falcon? I'll
> revert these two, in that case...
>
> Cheers,
> Chema
>
> 2012/12/19 Carol Frampton <cf...@adobe.com>
>
> > svn commit: r1423864 looks like it falls in the same category and
> > should be reverted
> >
> > Carol
> >
> >
> >
> > On 12/19/12 3 :07PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> >
> > >HI,
> > >
> > >> + var parseFunction:Function = this.parseFunction;
> > >
> > >
> > >Wouldn't it be better to fix Flacon rather than change the SDK in
> > >this way? Seems a bit hackish to me.
> > >
> > >Thanks,
> > >Justin
> > >
> >
> >
>
RE: svn commit: r1423863 -
/incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
Posted by Gordon Smith <go...@adobe.com>.
What is the type of newStyles? Is styleFunction of type Function?
- Gordon
-----Original Message-----
From: Chema Balsas [mailto:jbalsas@gmail.com]
Sent: Wednesday, December 19, 2012 12:47 PM
To: flex-dev@incubator.apache.org
Subject: Re: svn commit: r1423863 - /incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
The error in OLAPDatagrid.as was
Error: Implicit coercion of a value of type IOLAPAxisPosition to an
> unrelated type Function.
> newStyles = styleFunction(rowPosn, colPosn, cellValue);
> ^
Both may be related with a setter with that name being defined in the same class.
@Gordon is this something you'll be taking care of inside Falcon? I'll revert these two, in that case...
Cheers,
Chema
2012/12/19 Carol Frampton <cf...@adobe.com>
> svn commit: r1423864 looks like it falls in the same category and
> should be reverted
>
> Carol
>
>
>
> On 12/19/12 3 :07PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>
> >HI,
> >
> >> + var parseFunction:Function = this.parseFunction;
> >
> >
> >Wouldn't it be better to fix Flacon rather than change the SDK in
> >this way? Seems a bit hackish to me.
> >
> >Thanks,
> >Justin
> >
>
>
Re: svn commit: r1423863 -
/incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
Posted by Alex Harui <ah...@adobe.com>.
Hi Chema,
The policy should be to not change valid and correct AS code in the SDK just
because Falcon cannot compile it. There will be times when we will change
the SDK code because Falcon is stricter than MXMLC, but I don't think these
changes fall into that category.
Thanks,
-Alex
On 12/19/12 12:46 PM, "Chema Balsas" <jb...@gmail.com> wrote:
> The error in OLAPDatagrid.as was
>
> Error: Implicit coercion of a value of type IOLAPAxisPosition to an
>> unrelated type Function.
>> newStyles = styleFunction(rowPosn, colPosn, cellValue);
>> ^
>
>
> Both may be related with a setter with that name being defined in the same
> class.
>
> @Gordon is this something you'll be taking care of inside Falcon? I'll
> revert these two, in that case...
>
> Cheers,
> Chema
>
> 2012/12/19 Carol Frampton <cf...@adobe.com>
>
>> svn commit: r1423864 looks like it falls in the same category and should
>> be reverted
>>
>> Carol
>>
>>
>>
>> On 12/19/12 3 :07PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>>
>>> HI,
>>>
>>>> + var parseFunction:Function = this.parseFunction;
>>>
>>>
>>> Wouldn't it be better to fix Flacon rather than change the SDK in this
>>> way? Seems a bit hackish to me.
>>>
>>> Thanks,
>>> Justin
>>>
>>
>>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: svn commit: r1423863 - /incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
Posted by Chema Balsas <jb...@gmail.com>.
The error in OLAPDatagrid.as was
Error: Implicit coercion of a value of type IOLAPAxisPosition to an
> unrelated type Function.
> newStyles = styleFunction(rowPosn, colPosn, cellValue);
> ^
Both may be related with a setter with that name being defined in the same
class.
@Gordon is this something you'll be taking care of inside Falcon? I'll
revert these two, in that case...
Cheers,
Chema
2012/12/19 Carol Frampton <cf...@adobe.com>
> svn commit: r1423864 looks like it falls in the same category and should
> be reverted
>
> Carol
>
>
>
> On 12/19/12 3 :07PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>
> >HI,
> >
> >> + var parseFunction:Function = this.parseFunction;
> >
> >
> >Wouldn't it be better to fix Flacon rather than change the SDK in this
> >way? Seems a bit hackish to me.
> >
> >Thanks,
> >Justin
> >
>
>
RE: svn commit: r1423863 -
/incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
Posted by Gordon Smith <go...@adobe.com>.
I'm trying to understand whether this error is a Falcon bug or not. What was the type of d, the type of v, and the type of parseFunction?
- Gordon
-----Original Message-----
From: Chema Balsas [mailto:jbalsas@gmail.com]
Sent: Wednesday, December 19, 2012 12:19 PM
To: flex-dev@incubator.apache.org
Subject: Re: svn commit: r1423863 - /incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
Hi,
The error was
Error: Implicit coercion of a value with static type Object to a possibly
> unrelated type Function.
> d = parseFunction(v);
In this case, I used that "hackish" construction because I saw it was already used somewhere else in the existing code. For example, you can find it in
line 1334 in DateTimeAxis.as
line 377 in LogAxis.as
Of course, I'm open to suggestions :)
Cheers,
Chema
2012/12/19 Gordon Smith <go...@adobe.com>
> What error or warning did Falcon produce without this?
>
> - Gordon
>
> -----Original Message-----
> From: Justin Mclean [mailto:justin@classsoftware.com]
> Sent: Wednesday, December 19, 2012 12:07 PM
> To: flex-dev@incubator.apache.org
> Subject: Re: svn commit: r1423863 -
> /incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx
> /charts/DateTimeAxis.as
>
> HI,
>
> > + var parseFunction:Function = this.parseFunction;
>
>
> Wouldn't it be better to fix Flacon rather than change the SDK in this
> way? Seems a bit hackish to me.
>
> Thanks,
> Justin
>
>
Re: svn commit: r1423863 - /incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
Posted by Chema Balsas <jb...@gmail.com>.
Hi,
The error was
Error: Implicit coercion of a value with static type Object to a possibly
> unrelated type Function.
> d = parseFunction(v);
In this case, I used that "hackish" construction because I saw it was
already used somewhere else in the existing code. For example, you can find
it in
line 1334 in DateTimeAxis.as
line 377 in LogAxis.as
Of course, I'm open to suggestions :)
Cheers,
Chema
2012/12/19 Gordon Smith <go...@adobe.com>
> What error or warning did Falcon produce without this?
>
> - Gordon
>
> -----Original Message-----
> From: Justin Mclean [mailto:justin@classsoftware.com]
> Sent: Wednesday, December 19, 2012 12:07 PM
> To: flex-dev@incubator.apache.org
> Subject: Re: svn commit: r1423863 -
> /incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
>
> HI,
>
> > + var parseFunction:Function = this.parseFunction;
>
>
> Wouldn't it be better to fix Flacon rather than change the SDK in this
> way? Seems a bit hackish to me.
>
> Thanks,
> Justin
>
>
RE: svn commit: r1423863 -
/incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
Posted by Gordon Smith <go...@adobe.com>.
What error or warning did Falcon produce without this?
- Gordon
-----Original Message-----
From: Justin Mclean [mailto:justin@classsoftware.com]
Sent: Wednesday, December 19, 2012 12:07 PM
To: flex-dev@incubator.apache.org
Subject: Re: svn commit: r1423863 - /incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
HI,
> + var parseFunction:Function = this.parseFunction;
Wouldn't it be better to fix Flacon rather than change the SDK in this way? Seems a bit hackish to me.
Thanks,
Justin
Re: svn commit: r1423863 -
/incubator/flex/sdk/branches/develop/frameworks/projects/charts/src/mx/charts/DateTimeAxis.as
Posted by Carol Frampton <cf...@adobe.com>.
svn commit: r1423864 looks like it falls in the same category and should
be reverted
Carol
On 12/19/12 3 :07PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>HI,
>
>> + var parseFunction:Function = this.parseFunction;
>
>
>Wouldn't it be better to fix Flacon rather than change the SDK in this
>way? Seems a bit hackish to me.
>
>Thanks,
>Justin
>