You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Martin Heidegger <mh...@leichtgewicht.at> on 2012/02/24 06:28:56 UTC
[CODE] Short cleanup
Hello List,
today I read/skimmed over the Flex SDK and found a lot of missing ";" in
the Flex SDK, as well as a few unused private methods or method
arguments and imports.
I committed the ones I found to a github fork [1]. Perhaps some changes
can go into the SDK?
However I wondered about a few things related to the Flex coding style:
- Spaces or tabs? I found that various files currently mix spaces and
tabs, some have more tabs some more spaces (what was the policy again?)
- include: It is not my personal style to use includes in the SDK,
however: Wouldn't it be good if we moved them to classes not named
"*.as" but rather "*.as.inc"?
- Version.as: What for do we need that included in every class? Isn't
that a little excessive? What do we gain from it?
- Use of if( "" in obj) or if(obj.hasOwnProperty("")) - which is
recommended?
yours
Martin.
[1] https://github.com/martinheidegger/flex/compare/master
Re: [CODE] Short cleanup
Posted by Omar Gonzalez <om...@gmail.com>.
On Fri, Feb 24, 2012 at 12:04 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 2/23/12 11:55 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>
> > Hi,
> >
> >> I think using the localechanges branch should be fine, no? We could use
> it
> >> to stage all the things we'd like to bring in as soon as Mustella makes
> its
> >> way in and we can test the framework.
> >
> > Might be better it it had a different name if it contains more than the
> locale
> > changes.
> True, but I don't care what you call it. It will hopefully be temporary.
> I
> don't see the need for multiple temporary branches.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
I agree here, I didn't think the branch now named localchanges was really
meant to segregate just those changes but simply to minimize the
possibility of conflicts and problems in the trunk as we get Apache Infra
to import more SVN dumps. i dont see the real need for having a bunch of
branches to stage those patches either.
--
Omar Gonzalez
s9tpepper@apache.org
Apache Flex PPMC Member
Re: [CODE] Short cleanup
Posted by Omar Gonzalez <om...@gmail.com>.
On Thu, Feb 23, 2012 at 11:55 PM, Justin Mclean <ju...@classsoftware.com>wrote:
> Hi,
>
> > I think using the localechanges branch should be fine, no? We could use
> it
> > to stage all the things we'd like to bring in as soon as Mustella makes
> its
> > way in and we can test the framework.
>
> Might be better it it had a different name if it contains more than the
> locale changes.
>
> Justin
I don't think you can rename a branch, but maybe that's a good idea. Name
it patchStaging? Or another branch if you think they're going to get nasty,
the changes that is. After all, that's what SVN is for right? Branching and
stuff. :)
--
Omar Gonzalez
s9tpepper@apache.org
Apache Flex PPMC Member
Re: [CODE] Short cleanup
Posted by Alex Harui <ah...@adobe.com>.
On 2/23/12 11:55 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
>> I think using the localechanges branch should be fine, no? We could use it
>> to stage all the things we'd like to bring in as soon as Mustella makes its
>> way in and we can test the framework.
>
> Might be better it it had a different name if it contains more than the locale
> changes.
True, but I don't care what you call it. It will hopefully be temporary. I
don't see the need for multiple temporary branches.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [CODE] Short cleanup
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I think using the localechanges branch should be fine, no? We could use it
> to stage all the things we'd like to bring in as soon as Mustella makes its
> way in and we can test the framework.
Might be better it it had a different name if it contains more than the locale changes.
Justin
Re: [CODE] Short cleanup
Posted by Omar Gonzalez <om...@gmail.com>.
I think using the localechanges branch should be fine, no? We could use it
to stage all the things we'd like to bring in as soon as Mustella makes its
way in and we can test the framework.
--
Omar Gonzalez
s9tpepper@apache.org
Apache Flex PPMC Member
Re: [CODE] Short cleanup
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> today I read/skimmed over the Flex SDK and found a lot of missing ";"
Semicolons are optional in a lot of cases but I it would be good to see them in there for constancy sake.
> a few unused private methods or method arguments and imports.
It most cases I agree they should be removed. In one or two of the missing method argument is possible they should left as a reminder that the method could be optimised if it used those parameters.
Currently we don't have any way of testing changes to the framework so unfortunately it's not really possible to check changes into the SVN trunk. We also don't want to cause any potential issues for upcoming donations from Adobe and the initial Apache parity release. However I'm all for changes like this to be submitted into a SVN branch and merged at a later date.
Do other PPMC members/commiters see any issue with this? We might end up with a few branches and some potential merge issues down the track but nothing that should be too hard to sort out.
Following correct procedure a JIRA entry need to be created for this (perhaps more than one? One for missing semicolons, one for imports etc) and patches generated.
Thanks,
Justin
Re: [CODE] Short cleanup
Posted by Omar Gonzalez <om...@gmail.com>.
I believe "in" works only on dynamic classes, like plain Object. You have
to use hasOwnProperty() when the key is declared as a member of a class, or
a 'sealed class'. At least that's how it works in loops.
--
Omar Gonzalez
s9tpepper@apache.org
Apache Flex PPMC Member
RE: [CODE] Short cleanup
Posted by David Arno <da...@davidarno.org>.
> From: Left Right [mailto:olegsivokon@gmail.com]
> Sent: 24 February 2012 11:10
> OMG!!! Seriously, you are writing SDK code and you don't know what's the
> difference between using `in' operator and calling a method defined on
> Object.prototype is?
Interesting. Seeing someone else by rude brings home to me why people didn't
like me doing it.
Left Right,
What are the benefits / disadvantages of
if (collection[item] !== undefined) ...
versus
if (item in collection) ...
The latter is easier on the eye, but does it have objective benefits (speed,
reliability etc)? I haven't tried it, but I suspect the former only works
properly if item is a string.
David.
Re: [CODE] Short cleanup
Posted by Alex Harui <ah...@adobe.com>.
On 2/24/12 3:46 AM, "olegsivokon@gmail.com" <ol...@gmail.com> wrote:
>
> There are other ways to identify the version -
>
> * @langversion 3.0
> * @playerversion Flash 9
> * @playerversion AIR 1.1
> * @productversion Flex 3
>
> I don't see why this is not enough.
Where does this show up in the debugger?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [CODE] Short cleanup
Posted by Left Right <ol...@gmail.com>.
Before, when I tried to patch the framework code, I'd routinely delete
`include "core/Version.as"' lines, it didn't seem to have any impact on the
existing code. This can be imprecise, because I'd usually try to reduce the
number of classes to compile, but it looks more like it wasn't used often
enough to justify the mandatory use.
There are other ways to identify the version -
* @langversion 3.0
* @playerversion Flash 9
* @playerversion AIR 1.1
* @productversion Flex 3
I don't see why this is not enough. If someone wants to be more pedantic,
then they can elaborate on @productversion. I'm not in favor of adding
compiler stamps, or extra metadata because the chances are it will quite
often became an obstacle rather then helper, just like a bunch of pointless
compiler warnings that MXMLC has, which actually resulted in that
programmers developed practices of writing bad code to only make the
compiler shut up ("missing parenthesis after function" warning is one such
example).
Re: [CODE] Short cleanup
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 24/02/2012 20:09, Left Right wrote:
> OMG!!! Seriously, you are writing SDK code and you don't know what's the
> difference between using `in' operator and calling a method defined on
> Object.prototype is?
Insulting doesn't help. I just haven't had the need to use this
structure up until now. (same goes for "include")
Not everything is needed for a clear code style. I am sure/hope we will
see submissions of people with a little less experienced than me.
> First of all, ...
>
> ...modular architecture failure.
Thanks for the detailed explanation. .hasOwnProperty is used at many
places within the Flex SDK.
> Further more, it isn't safe to use this function in mission-critical code,
> ...
This argument would make the use of .toString as not safe as well?!
yours
Martin.
Re: [CODE] Short cleanup
Posted by Left Right <ol...@gmail.com>.
OMG!!! Seriously, you are writing SDK code and you don't know what's the
difference between using `in' operator and calling a method defined on
Object.prototype is?
First of all, they are testing for different things. `in' is testing for a
key in a collection, key may or may not be a property, for example, a key
in the Dictionary is not a property. Object.prototype.hasOwnProperty() is a
slow to resolve and slow to execute function that will resolve the property
(which involves verifying access permissions and whether the enumeration of
the property is allowed). It is on average 4 times slower then `in' if it
is used to do the same thing.
Further more, whilst `in' has several legitimate use cases (such as
verifying whether the collection contains the key),
Object.prototype.hasOwnProperty() is usually an indication that you are
doing something wrong. For example, you did not define an interface to
abstract different object types for similar access, or you created a blob
class, you don't want to import because of too many dependencies - modular
architecture failure.
Further more, it isn't safe to use this function in mission-critical code,
because someone can easily redefine it for __every__ object in the project,
since it's defined on the prototype, and by redefining it may intercept
some of your data you passed to this function.
Re: [CODE] Short cleanup
Posted by Alex Harui <ah...@adobe.com>.
On 2/24/12 11:18 AM, "olegsivokon@gmail.com" <ol...@gmail.com> wrote:
>> Sorry, I don't understand your response.
> Look at what file you are debugging, copy the name, cat, grep, you see what
> you need...
I don't think that works given that the filename path is based on what the
build machine had, not what is on my system, but thanks for your first short
replies ;=)
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [CODE] Short cleanup
Posted by Left Right <ol...@gmail.com>.
> Sorry, I don't understand your response.
Look at what file you are debugging, copy the name, cat, grep, you see what
you need...
Re: [CODE] Short cleanup
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 25/02/2012 03:44, Alex Harui wrote:
> Helped me a few times. Seems worth it to me. Don't we have bigger fish to
> fry?
My question was: Can I clean that up? And up until now I haven't found a
good
reason as to why I couldn't. I have never ... never ever had that
problem but I can
somehow accept that others have.
However: I will write down the former concept to improve the swc
description files
and versions so we can have finally some real versioning that makes sense.
yours
Martin.
Re: [CODE] Short cleanup
Posted by Alex Harui <ah...@adobe.com>.
On 2/24/12 10:38 AM, "Martin Heidegger" <mh...@leichtgewicht.at> wrote:
> Not too helpful imho.
Helped me a few times. Seems worth it to me. Don't we have bigger fish to
fry?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [CODE] Short cleanup
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
> We don't have to test since there is an include.
The include just makes sure that the class has a different hash at every
release. This hash does not get checked
for swcs or runtime loading - I just reconfirmed that. Compiler as well
as flash.display.Loader ignore the hash and the version
number. All it can be used for is see if the name of the loaded class is
in-fact of a specific version. And that is only helps
if you look carefully in the debugger.
Not too helpful imho.
>> All those version numbers are noise that bloats the swf size,
>> documentation and API and results
>> in maintenance.
> Remember, the string is in the constant pool, so it is one class trait entry
> per class.
Still... how many classes are in the flex sdk? They are of the namespace
mx_internal: accessible from everywhere with
the right prefix. They also shine up in describeType. I think "noise" is
a good summary.
>> In the compile process the compiler could lookup each dependency of
>> different swcs. If they have the same
>> md5 hash he just uses the first one. If the md5 hashes differ it checks
>> if the version compatibility (if available).
> I think I still care about mismatches when loading SWFs as well, so not just
> compile time.
As the FlashPlayer doesn't support this kind of mechanism I suppose just
a sophisticated Loader
could provide this functionality but that would definitely cost quite a
bit of performance.
yours
Martin.
Re: [CODE] Short cleanup
Posted by Alex Harui <ah...@adobe.com>.
On 2/24/12 1:04 AM, "Martin Heidegger" <mh...@leichtgewicht.at> wrote:
>
> The proposal would make it easier to integrate version numbers but its
> the version numbers
> themselves that are a problem, included by "include" or build process or
> that new compiler feature.
What is the problem?
>
> What is the current workflow to test these version numbers? Obviously
> all classes of a swc will be
> invalidated right now on every release (even without changes at all)
We don't have to test since there is an include.
>
> All those version numbers are noise that bloats the swf size,
> documentation and API and results
> in maintenance.
Remember, the string is in the constant pool, so it is one class trait entry
per class.
>
> In the compile process the compiler could lookup each dependency of
> different swcs. If they have the same
> md5 hash he just uses the first one. If the md5 hashes differ it checks
> if the version compatibility (if available).
>
I think I still care about mismatches when loading SWFs as well, so not just
compile time.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [CODE] Short cleanup
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 24/02/2012 17:02, Alex Harui wrote:
> One day, folks started rejecting commits that had tabs. The developer
> most likely to have instituted such a policy expressed surprise at the
> policy as well, so I don't know who wanted it. Spaces are currently in
> the style guide, although there was a rule that you didn't have to
> un-tabify existing tabs.
Lets drop that rule? :) I know its hard to track changes between
versions if it contains tabs but just because of that sticking with that
tabs stuff is ridiculous imho.
> Just to save on maintenance. But I don't think they get used more than
> twice each, so I think there isn't much savings and you can just make
> them regular interfaces if you want.
I think interfaces are the way to go. Will try it out next days.
> Oh yeah, forgot about those. Also that way to reduce maintenance. Those
> things get used in many places. Frankly, style metadata is broken in the
> sense that a component has to have style metadata that really needs to be
> determined from the theme. That will take more work to fix, but we probably
> should otherwise new themes will be harder to work with.
I do not really like the current style system. But aside from that,
wouldn't it make sense to rename
them to *.style.inc so its not mistaken for working as3 code in the
editors.
> I thought it was you that proposed having the compiler stick in values it
> knows about.
The proposal would make it easier to integrate version numbers but its
the version numbers
themselves that are a problem, included by "include" or build process or
that new compiler feature.
What is the current workflow to test these version numbers? Obviously
all classes of a swc will be
invalidated right now on every release (even without changes at all)
All those version numbers are noise that bloats the swf size,
documentation and API and results
in maintenance.
Theoretically speaking: the compiler could put "dependency" metadata in
a swc.
When is the current swc built (timestamp) and against which libraries (md5)
- c.swc contains dependcy.xml
<swc timestamp="1235">
<compiled>
<type name="c.Some" md5="asdafas"/>
</compiled>
<external-dependency>
<type name="foo.bar.One" md5="abdcsgfgagasdf" />
<type name="bar.foo.Other" md5="abdcsgasdfasdf" />
</external-dependency>
</swc>
It could be even improved using optiona metadata for versions:
<type name="foo.bar.One" md5="aabadsfasdfa" version="4.3" compatible="3"/>
Then it means that this particular class is API-compatible
(implementation differences) to another class with different hash.
In the compile process the compiler could lookup each dependency of
different swcs. If they have the same
md5 hash he just uses the first one. If the md5 hashes differ it checks
if the version compatibility (if available).
> You are welcome, although Omar had the exact opposite answer.
Both gives me reasoning to explore. Before I had no idea.
yours
Martin.
Re: [CODE] Short cleanup
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
>> An easier solution may be using the build scripts to stick in the version
>> number?
> Can that work when developing as an FB project?
Don't see why not. As I've played about with the build scripts a bit I'll take a look at it.
Justin
Re: [CODE] Short cleanup
Posted by Alex Harui <ah...@adobe.com>.
On 2/24/12 12:10 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
>> I thought it was you that proposed having the compiler stick in values it
>> knows about. Seems like that could be extended to stick in a version
>> number.
> An easier solution may be using the build scripts to stick in the version
> number?
Can that work when developing as an FB project?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [CODE] Short cleanup
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I thought it was you that proposed having the compiler stick in values it
> knows about. Seems like that could be extended to stick in a version
> number.
An easier solution may be using the build scripts to stick in the version number?
Justin
Re: [CODE] Short cleanup
Posted by Alex Harui <ah...@adobe.com>.
On 2/23/12 11:32 PM, "Martin Heidegger" <mh...@leichtgewicht.at> wrote:
> On 24/02/2012 15:17, Alex Harui wrote:
>> Somehow, the policy became 4 spaces. Personally I don't care if it is
>> a four-space tab or four spaces, but definitely not 8 spaces although
>> some of that did get in there.
>
> What do you mean "somehow"? I don't care as well - there are bad
> arguments for either - but I think we should settle on one of both.
One day, folks started rejecting commits that had tabs. The developer most
likely to have instituted such a policy expressed surprise at the policy as
well, so I don't know who wanted it. Spaces are currently in the style
guide, although there was a rule that you didn't have to un-tabify existing
tabs.
>
>> Includes should only be in two places: version.as, and some interfaces
>> that mirror some flash.display.* classes. I don't think any of the
>> latter includes are used more than twice, so it might be simpler to
>> just copy and paste the includes into the files that use them and get
>> rid of the includes.
>
> They are used for some hefty interfaces like ISpriteInterface or
> IDisplayObjectInterface - I am wondering why they are not regular
> interfaces - why import them if they could be extended?
Just to save on maintenance. But I don't think they get used more than
twice each, so I think there isn't much savings and you can just make them
regular interfaces if you want.
> Also a lot of
> Style and other Metadata tags are included like this. I guess to reduce
> the maintenance (inheritance or delegation seem not to work in those cases).
Oh yeah, forgot about those. Also that way to reduce maintenance. Those
things get used in many places. Frankly, style metadata is broken in the
sense that a component has to have style metadata that really needs to be
determined from the theme. That will take more work to fix, but we probably
should otherwise new themes will be harder to work with.
>
>> It is used to detect if someone mixed classes from different versions
>> (and didn't get some earlier failure). I want to have a version stamp
>> in each class. You proposed a compiler change that could eliminate
>> version.as, I think.
>
> No I didn't - at least not that I remember. However: I don't really
> think that this solves any problem. I mean: What if I use classes
> from different versions? Will it throw an error? Not that I know of.
> Just in debugging I might see that. To me the only reasonable
> solution for this is a maven like dependency-tree or md5 hashes (who
> cares if its from different versions if it does exactly
> the same thing).
>
I thought it was you that proposed having the compiler stick in values it
knows about. Seems like that could be extended to stick in a version
number. The version stamps are there to catch folks mixing versions with
subtle differences. If there is an API difference you should get a verify
error much earlier. If the code is the same you are right it doesn't
matter, but if the API surface is the same and there is a behavior
difference, it seems like a worthwhile thing to have an easy way to detect
that. Is this solution unreasonable to you because it uses includes?
>> Way back when, we were told to use if ( "" in obj) for "sealed" classes and
>> hasOwnProperty for dynamic objects. The documentation doesn't say that and
>> I haven't tested speed. And, hasOwnProperty must be used in some prototype
>> inheritance cases.
> Thanks for clarification (Omar too).
You are welcome, although Omar had the exact opposite answer.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [CODE] Short cleanup
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 24/02/2012 15:17, Alex Harui wrote:
> Somehow, the policy became 4 spaces. Personally I don't care if it is
> a four-space tab or four spaces, but definitely not 8 spaces although
> some of that did get in there.
What do you mean "somehow"? I don't care as well - there are bad
arguments for either - but I think we should settle on one of both.
> Includes should only be in two places: version.as, and some interfaces
> that mirror some flash.display.* classes. I don't think any of the
> latter includes are used more than twice, so it might be simpler to
> just copy and paste the includes into the files that use them and get
> rid of the includes.
They are used for some hefty interfaces like ISpriteInterface or
IDisplayObjectInterface - I am wondering why they are not regular
interfaces - why import them if they could be extended? Also a lot of
Style and other Metadata tags are included like this. I guess to reduce
the maintenance (inheritance or delegation seem not to work in those cases).
> It is used to detect if someone mixed classes from different versions
> (and didn't get some earlier failure). I want to have a version stamp
> in each class. You proposed a compiler change that could eliminate
> version.as, I think.
No I didn't - at least not that I remember. However: I don't really
think that this solves any problem. I mean: What if I use classes
from different versions? Will it throw an error? Not that I know of.
Just in debugging I might see that. To me the only reasonable
solution for this is a maven like dependency-tree or md5 hashes (who
cares if its from different versions if it does exactly
the same thing).
> Way back when, we were told to use if ( "" in obj) for "sealed" classes and
> hasOwnProperty for dynamic objects. The documentation doesn't say that and
> I haven't tested speed. And, hasOwnProperty must be used in some prototype
> inheritance cases.
Thanks for clarification (Omar too).
yours
Martin.
RE: [CODE] Short cleanup
Posted by Gordon Smith <go...@adobe.com>.
I don't think you can do 'ant package' without Cygwin.
- Gordon
-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com]
Sent: Friday, February 24, 2012 3:12 PM
To: flex-dev@incubator.apache.org
Subject: Re: [CODE] Short cleanup
On 2/24/12 1:59 PM, "Gordon Smith" <go...@adobe.com> wrote:
> Windows builds already require Cygwin and sed seems to be part of the
> default Cygwin installation.
>
> It would be nice, though, if Cygwin wasn't required.
>
> - Gordon Smith, Adobe
I build all the time without Cygwin on Windows. At least the main and checkintests. It might be that the doc targets need Cygwin.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [CODE] Short cleanup
Posted by Carol Frampton <cf...@adobe.com>.
I don't like this approach. The replaced tag will surely get submitted.
I really don't understand why so much attention has been devoted to this
today. There are so many other things to do.
Carol
On 2/24/12 5 :19PM, "Om" <bi...@gmail.com> wrote:
>I like this approach. This is how we bake in application version numbers,
>build timestamp, etc. while compiling release builds of Flex apps we ship.
>
>
>
>> Minor issue with this is that now the Version.as files are out of sync
>> with SVN, could accidentally be checked back in with wrong version
>>numbers
>> or the like.
>>
>> I guess there's the more philosophical question of do we really want
>>ANT
>> scripts that modify the source code?
>>
>
>We can revert Version.as to its original state after compiling or just not
>check in the changed Version.as. A carefully constructed build script
>should do the trick. This way we don't really care if Ant is making
>changes to the source code.
>
>Om
>
>On Fri, Feb 24, 2012 at 2:11 PM, Justin Mclean
><ju...@classsoftware.com>wrote:
>
>> Hi,
>>
>> ANT can do this quite easily.
>>
>> If we change all Version.as files to be like so:
>> mx_internal static const VERSION:String = "@release@";
>>
>> Then this target will inject the version number into all Version.as
>>files:
>> <target name="setFlexSDKVersion">
>> <replace dir="${basedir}" includes="**/Version.as"
>>token="@release@"
>> value="${release.version}.${build.number}" />
>> </target>
>>
>> We have these currently in the build file:
>> <property name="release.version" value="4.6.0"/>
>> <property name="build.number" value="0"/>
>>
>> So that would replace every occurrence of "@release@" with "4.6.0.0".
>>
>> Minor issue with this is that now the Version.as files are out of sync
>> with SVN, could accidentally be checked back in with wrong version
>>numbers
>> or the like.
>>
>> I guess there's the more philosophical question of do we really want
>>ANT
>> scripts that modify the source code?
>>
>> Justin
>>
>>
>>
>>
Re: [CODE] Short cleanup
Posted by Jonathan Campos <jo...@gmail.com>.
On Fri, Feb 24, 2012 at 4:26 PM, Gordon Smith <go...@adobe.com> wrote:
> I think it would be better to have the VERSION constant injected by the
> compiler. Alex wants it in every class but we sometimes forget to put in
> the include statement or an explicit VERSION constant. And then it's just a
> build option and the source code doesn't have to be preprocessed.
I'm more in favor with that idea. I definitely have been helped by getting
the version from the running code and would like to not see that disappear.
--
Jonathan Campos
Re: [CODE] Short cleanup
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I think it would be better to have the VERSION constant injected by the compiler.
That would be my preferred option but only if it's easily possible. I assume it's a little harder to do than a a couple of files of ANT? I assume we wouldn't want this added to all classes just the SDK one so would have to be some condition based on a list of namespaces (which may change?) Not having looked at the code I'm just guessing here and could be way off the mark.
And not sure it could deal with the constants in FlexVersion.as such as:
public static const CURRENT_VERSION:uint = 0x04060000;
public static const VERSION_4_6:uint = 0x04060000;
Which an ANT script would be able to. This file could be hand edited each time (as I assume has been done in the past) but would be nice if the Flex SDK version was set somewhere just once and all changes follow on from that.
Thanks,
Justin
RE: [CODE] Short cleanup
Posted by Gordon Smith <go...@adobe.com>.
I think it would be better to have the VERSION constant injected by the compiler. Alex wants it in every class but we sometimes forget to put in the include statement or an explicit VERSION constant. And then it's just a build option and the source code doesn't have to be preprocessed.
- Gordon Smith, Adobe
-----Original Message-----
From: omuppi1@gmail.com [mailto:omuppi1@gmail.com] On Behalf Of Om
Sent: Friday, February 24, 2012 2:20 PM
To: flex-dev@incubator.apache.org
Subject: Re: [CODE] Short cleanup
I like this approach. This is how we bake in application version numbers, build timestamp, etc. while compiling release builds of Flex apps we ship.
> Minor issue with this is that now the Version.as files are out of sync
> with SVN, could accidentally be checked back in with wrong version
> numbers or the like.
>
> I guess there's the more philosophical question of do we really want
> ANT scripts that modify the source code?
>
We can revert Version.as to its original state after compiling or just not check in the changed Version.as. A carefully constructed build script should do the trick. This way we don't really care if Ant is making changes to the source code.
Om
On Fri, Feb 24, 2012 at 2:11 PM, Justin Mclean <ju...@classsoftware.com>wrote:
> Hi,
>
> ANT can do this quite easily.
>
> If we change all Version.as files to be like so:
> mx_internal static const VERSION:String = "@release@";
>
> Then this target will inject the version number into all Version.as files:
> <target name="setFlexSDKVersion">
> <replace dir="${basedir}" includes="**/Version.as" token="@release@"
> value="${release.version}.${build.number}" /> </target>
>
> We have these currently in the build file:
> <property name="release.version" value="4.6.0"/> <property
> name="build.number" value="0"/>
>
> So that would replace every occurrence of "@release@" with "4.6.0.0".
>
> Minor issue with this is that now the Version.as files are out of sync
> with SVN, could accidentally be checked back in with wrong version
> numbers or the like.
>
> I guess there's the more philosophical question of do we really want
> ANT scripts that modify the source code?
>
> Justin
>
>
>
>
Re: [CODE] Short cleanup
Posted by Om <bi...@gmail.com>.
I like this approach. This is how we bake in application version numbers,
build timestamp, etc. while compiling release builds of Flex apps we ship.
> Minor issue with this is that now the Version.as files are out of sync
> with SVN, could accidentally be checked back in with wrong version numbers
> or the like.
>
> I guess there's the more philosophical question of do we really want ANT
> scripts that modify the source code?
>
We can revert Version.as to its original state after compiling or just not
check in the changed Version.as. A carefully constructed build script
should do the trick. This way we don't really care if Ant is making
changes to the source code.
Om
On Fri, Feb 24, 2012 at 2:11 PM, Justin Mclean <ju...@classsoftware.com>wrote:
> Hi,
>
> ANT can do this quite easily.
>
> If we change all Version.as files to be like so:
> mx_internal static const VERSION:String = "@release@";
>
> Then this target will inject the version number into all Version.as files:
> <target name="setFlexSDKVersion">
> <replace dir="${basedir}" includes="**/Version.as" token="@release@"
> value="${release.version}.${build.number}" />
> </target>
>
> We have these currently in the build file:
> <property name="release.version" value="4.6.0"/>
> <property name="build.number" value="0"/>
>
> So that would replace every occurrence of "@release@" with "4.6.0.0".
>
> Minor issue with this is that now the Version.as files are out of sync
> with SVN, could accidentally be checked back in with wrong version numbers
> or the like.
>
> I guess there's the more philosophical question of do we really want ANT
> scripts that modify the source code?
>
> Justin
>
>
>
>
Re: [CODE] Short cleanup
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
ANT can do this quite easily.
If we change all Version.as files to be like so:
mx_internal static const VERSION:String = "@release@";
Then this target will inject the version number into all Version.as files:
<target name="setFlexSDKVersion">
<replace dir="${basedir}" includes="**/Version.as" token="@release@" value="${release.version}.${build.number}" />
</target>
We have these currently in the build file:
<property name="release.version" value="4.6.0"/>
<property name="build.number" value="0"/>
So that would replace every occurrence of "@release@" with "4.6.0.0".
Minor issue with this is that now the Version.as files are out of sync with SVN, could accidentally be checked back in with wrong version numbers or the like.
I guess there's the more philosophical question of do we really want ANT scripts that modify the source code?
Justin
Re: [CODE] Short cleanup
Posted by Alex Harui <ah...@adobe.com>.
On 2/24/12 1:59 PM, "Gordon Smith" <go...@adobe.com> wrote:
> Windows builds already require Cygwin and sed seems to be part of the default
> Cygwin installation.
>
> It would be nice, though, if Cygwin wasn't required.
>
> - Gordon Smith, Adobe
I build all the time without Cygwin on Windows. At least the main and
checkintests. It might be that the doc targets need Cygwin.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
RE: [CODE] Short cleanup
Posted by Gordon Smith <go...@adobe.com>.
Windows builds already require Cygwin and sed seems to be part of the default Cygwin installation.
It would be nice, though, if Cygwin wasn't required.
- Gordon Smith, Adobe
-----Original Message-----
From: Maciek Sakrejda [mailto:m.sakrejda@gmail.com]
Sent: Friday, February 24, 2012 1:51 PM
To: flex-dev@incubator.apache.org
Subject: Re: [CODE] Short cleanup
On Fri, Feb 24, 2012 at 1:47 PM, Left Right <ol...@gmail.com> wrote:
> Erm... sed is just as crossplatform as Ant :) but, really, I didn't mean to argue.
Meant that in the sense that we require ant to be present for builds already, and while you can expect that sed is installed on OS X and *nix platforms, we can't reasonably add this requirement to Windows builds.
Re: [CODE] Short cleanup
Posted by Maciek Sakrejda <m....@gmail.com>.
On Fri, Feb 24, 2012 at 1:47 PM, Left Right <ol...@gmail.com> wrote:
> Erm... sed is just as crossplatform as Ant :) but, really, I didn't mean to argue.
Meant that in the sense that we require ant to be present for builds
already, and while you can expect that sed is installed on OS X and
*nix platforms, we can't reasonably add this requirement to Windows
builds.
Re: [CODE] Short cleanup
Posted by Left Right <ol...@gmail.com>.
Erm... sed is just as crossplatform as Ant :) but, really, I didn't mean to
argue. I'm used to compile with patches, besides, since signed RSLs are no
longer an option, (so far I understand it) - that doesn't matter, if I'll
compile for production, I'll probably have much more patches to apply, so
that's fine.
By the way, is there any decision on how SDK is compiled? I would be
willing to write a scons build (I am not an expert in scons, but I liked
what I saw, and that would be an interesting learning exercise). I know,
I'd need to start another thread, if there's not already, sorry for the
flame :)
Re: [CODE] Short cleanup
Posted by Maciek Sakrejda <m....@gmail.com>.
On Fri, Feb 24, 2012 at 1:22 PM, Left Right <ol...@gmail.com> wrote:
> But, whatever,
> it doesn't hurt me to run sed -i s/inculde ...// before compiling :)
If you're adamant about this, you may even be able to convince Apache
to accept this as an optional flag to the official build scripts (I
think ant's filters could do the trick here in a cross-platform
fashion instead of sed).
Re: [CODE] Short cleanup
Posted by Left Right <ol...@gmail.com>.
Nothing real-time, but yeah, that's part of my job... like many of other
programmers hear... well, I guess. I never needed version numbers, besides
SDK versions and my (or other developer) project versions. But, whatever,
it doesn't hurt me to run sed -i s/inculde ...// before compiling :)
Re: [CODE] Short cleanup
Posted by Alex Harui <ah...@adobe.com>.
On 2/24/12 12:50 PM, "olegsivokon@gmail.com" <ol...@gmail.com> wrote:
> Ah, so you mean you were recompiling a module SWF and reloading it, while
> the other half was still in debugger? I'm not sure, but I think that the
> policy as to load and unload is per domain... but, that's something I
> really don't know. Is it possible that after unloading a SWF only some
> class definitions would "stuck" in the player? Sounds fishy :)
>
> In other aspects, I didn't mean "no version at all", I'm for "per SWF", so
> if the entire SWF was cached, then you would discover it by looking at the
> version in SWF.
I would like per-class. SWCs can get mixed from all over the place, then
loaded in via a module (and not be blocked by some pre-existing definition).
Have either of you handled time-sensitive escalations from enterprise
customers with code written by folks you don't know? That's been part of my
job and probably will continue to be so, and version stamping the classes
helped me out in a way that per-SWF won't and compile time checking won't.
I will not appreciate making that task harder. I cannot understand the
amount of energy being spent on this low overhead solution. I think we have
much bigger fish to fry.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [CODE] Short cleanup
Posted by Left Right <ol...@gmail.com>.
Ah, so you mean you were recompiling a module SWF and reloading it, while
the other half was still in debugger? I'm not sure, but I think that the
policy as to load and unload is per domain... but, that's something I
really don't know. Is it possible that after unloading a SWF only some
class definitions would "stuck" in the player? Sounds fishy :)
In other aspects, I didn't mean "no version at all", I'm for "per SWF", so
if the entire SWF was cached, then you would discover it by looking at the
version in SWF.
Re: [CODE] Short cleanup
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
If the swfs come from a server then things like caching can apply. Also:
when debugging it is a little stressful to compare the classes against
each-other.
yours
Martin.
Re: [CODE] Short cleanup
Posted by Left Right <ol...@gmail.com>.
And that would mean that you didn't know what classes you loaded, and what
classes where there before? Nah, unlikely... In the very worst case you can
just look up what class is in what SWF.
Re: [CODE] Short cleanup
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 25/02/2012 04:42, Left Right wrote:
> Well, you still have the source code. Debugging w/o the source is very
> unproductive, so you'd face many other issues before the absence of the
> version would become an issue. Lastly, why on the per class basis? And why,
> if you so much wanted to be consistent, you don't provide it for internal
> (private) classes? What if I wanted to know the version of internal class?
> How that would be different from wanting to know the version of any other
> class form the same build?
Theoretically: If you load different swfs with classes of the same name
then just the first
one will be accepted. So: if you have swfs with a half mixed class sets
(insane situation) then
it could be possible that some classes are loaded from version a and
some from version b.
To me: adding the version to swf-file-name is usually enough....
yours
Martin.
Re: [CODE] Short cleanup
Posted by Left Right <ol...@gmail.com>.
Well, you still have the source code. Debugging w/o the source is very
unproductive, so you'd face many other issues before the absence of the
version would become an issue. Lastly, why on the per class basis? And why,
if you so much wanted to be consistent, you don't provide it for internal
(private) classes? What if I wanted to know the version of internal class?
How that would be different from wanting to know the version of any other
class form the same build?
Re: [CODE] Short cleanup
Posted by David Francis Buhler <da...@gmail.com>.
We could format the entire SDK after it's available. In doing so, we would
gain initial uniformity.
If we decide to go this route, we can export all of the formatting settings
and come to a consensus about the format on-list. Afterwards, it would be
the responsibility of each developer to adhere to the standard, or, we
could just keep formatting the SDK.
On Fri, Feb 24, 2012 at 12:04 PM, Omar Gonzalez
<om...@gmail.com>wrote:
> On Fri, Feb 24, 2012 at 9:00 AM, Yennick Trevels
> <ye...@gmail.com>wrote:
>
> > I've got nothing against flexformatter, but it's an eclipse based plugin,
> > so we have to make sure that we don't make the rules too strict (aka
> > flexformatter specific) since also other IDE's are being used.
> >
> > On Fri, Feb 24, 2012 at 4:29 PM, Martin Heidegger <mh@leichtgewicht.at
> > >wrote:
> >
> > > On 25/02/2012 00:26, David Francis Buhler wrote:
> > >
> > >> Can we use FlexFormatter (BSD License?) and share a formatting
> > properties
> > >> file that adheres to a format reached by consensus?
> > >>
> > >> [1] http://sourceforge.net/**projects/flexformatter/<
> > http://sourceforge.net/projects/flexformatter/>
> > >>
> > > I don't see why not. The formatter properties could be hosted in the
> > wiki!
> > >
> > > cheers
> > > Martin.
> > >
> >
>
> I remember saying that the IntelliJ options pretty much can duplicate what
> we set up with FlexFormatter. Personally, I'll be using IntelliJ. It would
> be nice to come to an agreement on formatting rules though, it will make
> the code easier to work with as we have more and more people contributing
> code. It just takes a long time to set up the settings and I'm sure we'll
> all have some strong opinions on which way those settings go. I think its a
> good discussion to sort through before we get the rest of the donations
> from Adobe and really start hacking away at the codebase.
>
> --
> Omar Gonzalez
> s9tpepper@apache.org
> Apache Flex PPMC Member
>
Re: [CODE] Short cleanup
Posted by Omar Gonzalez <om...@gmail.com>.
On Fri, Feb 24, 2012 at 9:00 AM, Yennick Trevels
<ye...@gmail.com>wrote:
> I've got nothing against flexformatter, but it's an eclipse based plugin,
> so we have to make sure that we don't make the rules too strict (aka
> flexformatter specific) since also other IDE's are being used.
>
> On Fri, Feb 24, 2012 at 4:29 PM, Martin Heidegger <mh@leichtgewicht.at
> >wrote:
>
> > On 25/02/2012 00:26, David Francis Buhler wrote:
> >
> >> Can we use FlexFormatter (BSD License?) and share a formatting
> properties
> >> file that adheres to a format reached by consensus?
> >>
> >> [1] http://sourceforge.net/**projects/flexformatter/<
> http://sourceforge.net/projects/flexformatter/>
> >>
> > I don't see why not. The formatter properties could be hosted in the
> wiki!
> >
> > cheers
> > Martin.
> >
>
I remember saying that the IntelliJ options pretty much can duplicate what
we set up with FlexFormatter. Personally, I'll be using IntelliJ. It would
be nice to come to an agreement on formatting rules though, it will make
the code easier to work with as we have more and more people contributing
code. It just takes a long time to set up the settings and I'm sure we'll
all have some strong opinions on which way those settings go. I think its a
good discussion to sort through before we get the rest of the donations
from Adobe and really start hacking away at the codebase.
--
Omar Gonzalez
s9tpepper@apache.org
Apache Flex PPMC Member
Re: [CODE] Short cleanup
Posted by Alex Harui <ah...@adobe.com>.
On 2/24/12 10:13 AM, "olegsivokon@gmail.com" <ol...@gmail.com> wrote:
>> Where does this show up in the debugger?
> (fdb) file
> ney?
Sorry, I don't understand your response.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [CODE] Short cleanup
Posted by Left Right <ol...@gmail.com>.
Sorry, that was too short.
My opinion on versions - once per SWF is enough, no need to do it on per
class basis. (how other flash.* classes can live happily with only one
version defined in the player?) That's enough information, because if you
find yourself in a situation that some API you used had changed, then
knowing the version of the entire library is just the same as knowing the
version of a particular part of the library. That just won't add any new
information.
If you hope, that in the future framework will be reogranized in a way that
it's major parts won't make arbitrary dependencies to it's other parts,
then, probably, each part would deserve it's own version. As of today, that
doesn't make much sense, as you will need to work with a particular version
of the entire framework anyway.
Re: [CODE] Short cleanup
Posted by Left Right <ol...@gmail.com>.
> Where does this show up in the debugger?
(fdb) file
ney?
Re: [CODE] Short cleanup
Posted by Matthew Press <ma...@matthewpress.com>.
>
> I have some settings I use for FlexFormatter, I've just never compared
> them to what Adobe may be using, etc. I attached them to this email, not
> sure if it'll go through. Not saying these are exactly what we should use,
> but we need to start from somewhere.
>
> --
> Omar Gonzalez
> s9tpepper@apache.org
> Apache Flex PPMC Member
>
>
Your attachement seems to have got lost somewhere.
Apache does have its own standards:
http://portals.apache.org/development/code-standards.html
and then recommends following Sun's Java standards:
http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html
I think that would be a very good place to start, even though I disagree
with some of their recommendations.
They (unfortunately) advocate the spaces not tabs for some sound reasons.
Matt Press
Re: [CODE] Short cleanup
Posted by Omar Gonzalez <om...@gmail.com>.
On Fri, Feb 24, 2012 at 9:09 AM, Martin Heidegger <mh...@leichtgewicht.at>wrote:
> On 25/02/2012 02:00, Yennick Trevels wrote:
>
>> I've got nothing against flexformatter, but it's an eclipse based plugin,
>> so we have to make sure that we don't make the rules too strict (aka
>> flexformatter specific) since also other IDE's are being used.
>>
>
> You have a point there: FDT does not support all features of flexformatter
> and same goes for
> FlashDevelop. I could provide templates for those editors if someone
> defines the set for
> the flexformatter and notify you if something doesn't work out.
>
> yours
> Martin.
>
>
I have some settings I use for FlexFormatter, I've just never compared them
to what Adobe may be using, etc. I attached them to this email, not sure if
it'll go through. Not saying these are exactly what we should use, but we
need to start from somewhere.
--
Omar Gonzalez
s9tpepper@apache.org
Apache Flex PPMC Member
Re: [CODE] Short cleanup
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 25/02/2012 02:00, Yennick Trevels wrote:
> I've got nothing against flexformatter, but it's an eclipse based plugin,
> so we have to make sure that we don't make the rules too strict (aka
> flexformatter specific) since also other IDE's are being used.
You have a point there: FDT does not support all features of
flexformatter and same goes for
FlashDevelop. I could provide templates for those editors if someone
defines the set for
the flexformatter and notify you if something doesn't work out.
yours
Martin.
Re: [CODE] Short cleanup
Posted by Yennick Trevels <ye...@gmail.com>.
I've got nothing against flexformatter, but it's an eclipse based plugin,
so we have to make sure that we don't make the rules too strict (aka
flexformatter specific) since also other IDE's are being used.
On Fri, Feb 24, 2012 at 4:29 PM, Martin Heidegger <mh...@leichtgewicht.at>wrote:
> On 25/02/2012 00:26, David Francis Buhler wrote:
>
>> Can we use FlexFormatter (BSD License?) and share a formatting properties
>> file that adheres to a format reached by consensus?
>>
>> [1] http://sourceforge.net/**projects/flexformatter/<http://sourceforge.net/projects/flexformatter/>
>>
> I don't see why not. The formatter properties could be hosted in the wiki!
>
> cheers
> Martin.
>
Re: [CODE] Short cleanup
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 25/02/2012 00:26, David Francis Buhler wrote:
> Can we use FlexFormatter (BSD License?) and share a formatting properties
> file that adheres to a format reached by consensus?
>
> [1] http://sourceforge.net/projects/flexformatter/
I don't see why not. The formatter properties could be hosted in the wiki!
cheers
Martin.
Re: [CODE] Short cleanup
Posted by David Francis Buhler <da...@gmail.com>.
Can we use FlexFormatter (BSD License?) and share a formatting properties
file that adheres to a format reached by consensus?
[1] http://sourceforge.net/projects/flexformatter/
On Fri, Feb 24, 2012 at 10:03 AM, Carol Frampton <cf...@adobe.com> wrote:
> Alex may not care about tabs but I much prefer 4 spaces so that when I use
> various editors/tools that aren't configured for a tab to be 4 spaces the
> code isn't misaligned.
>
> On the subject of includes I know that two of the spark DataGrid
> itemRenderers use an include. I don't remember why it was done this way
> but I do know about 90% of the code is common.
>
> Carol
>
> On 2/24/12 1 :17AM, "Alex Harui" <ah...@adobe.com> wrote:
>
> >
> >
> >
> >On 2/23/12 9:28 PM, "Martin Heidegger" <mh...@leichtgewicht.at> wrote:
> >
> >> However I wondered about a few things related to the Flex coding style:
> >>
> >> - Spaces or tabs? I found that various files currently mix spaces and
> >> tabs, some have more tabs some more spaces (what was the policy again?)
> >Somehow, the policy became 4 spaces. Personally I don't care if it is a
> >four-space tab or four spaces, but definitely not 8 spaces although some
> >of
> >that did get in there.
> >> - include: It is not my personal style to use includes in the SDK,
> >> however: Wouldn't it be good if we moved them to classes not named
> >> "*.as" but rather "*.as.inc"?
> >Includes should only be in two places: version.as, and some interfaces
> >that
> >mirror some flash.display.* classes. I don't think any of the latter
> >includes are used more than twice, so it might be simpler to just copy and
> >paste the includes into the files that use them and get rid of the
> >includes.
> >
> >> - Version.as: What for do we need that included in every class? Isn't
> >> that a little excessive? What do we gain from it?
> >It is used to detect if someone mixed classes from different versions (and
> >didn't get some earlier failure). I want to have a version stamp in each
> >class. You proposed a compiler change that could eliminate version.as, I
> >think.
> >
> >> - Use of if( "" in obj) or if(obj.hasOwnProperty("")) - which is
> >> recommended?
> >Way back when, we were told to use if ( "" in obj) for "sealed" classes
> >and
> >hasOwnProperty for dynamic objects. The documentation doesn't say that
> >and
> >I haven't tested speed. And, hasOwnProperty must be used in some
> >prototype
> >inheritance cases.
> >
> >--
> >Alex Harui
> >Flex SDK Team
> >Adobe Systems, Inc.
> >http://blogs.adobe.com/aharui
> >
>
>
Re: [CODE] Short cleanup
Posted by Carol Frampton <cf...@adobe.com>.
Alex may not care about tabs but I much prefer 4 spaces so that when I use
various editors/tools that aren't configured for a tab to be 4 spaces the
code isn't misaligned.
On the subject of includes I know that two of the spark DataGrid
itemRenderers use an include. I don't remember why it was done this way
but I do know about 90% of the code is common.
Carol
On 2/24/12 1 :17AM, "Alex Harui" <ah...@adobe.com> wrote:
>
>
>
>On 2/23/12 9:28 PM, "Martin Heidegger" <mh...@leichtgewicht.at> wrote:
>
>> However I wondered about a few things related to the Flex coding style:
>>
>> - Spaces or tabs? I found that various files currently mix spaces and
>> tabs, some have more tabs some more spaces (what was the policy again?)
>Somehow, the policy became 4 spaces. Personally I don't care if it is a
>four-space tab or four spaces, but definitely not 8 spaces although some
>of
>that did get in there.
>> - include: It is not my personal style to use includes in the SDK,
>> however: Wouldn't it be good if we moved them to classes not named
>> "*.as" but rather "*.as.inc"?
>Includes should only be in two places: version.as, and some interfaces
>that
>mirror some flash.display.* classes. I don't think any of the latter
>includes are used more than twice, so it might be simpler to just copy and
>paste the includes into the files that use them and get rid of the
>includes.
>
>> - Version.as: What for do we need that included in every class? Isn't
>> that a little excessive? What do we gain from it?
>It is used to detect if someone mixed classes from different versions (and
>didn't get some earlier failure). I want to have a version stamp in each
>class. You proposed a compiler change that could eliminate version.as, I
>think.
>
>> - Use of if( "" in obj) or if(obj.hasOwnProperty("")) - which is
>> recommended?
>Way back when, we were told to use if ( "" in obj) for "sealed" classes
>and
>hasOwnProperty for dynamic objects. The documentation doesn't say that
>and
>I haven't tested speed. And, hasOwnProperty must be used in some
>prototype
>inheritance cases.
>
>--
>Alex Harui
>Flex SDK Team
>Adobe Systems, Inc.
>http://blogs.adobe.com/aharui
>
Re: [CODE] Short cleanup
Posted by Alex Harui <ah...@adobe.com>.
On 2/23/12 9:28 PM, "Martin Heidegger" <mh...@leichtgewicht.at> wrote:
> However I wondered about a few things related to the Flex coding style:
>
> - Spaces or tabs? I found that various files currently mix spaces and
> tabs, some have more tabs some more spaces (what was the policy again?)
Somehow, the policy became 4 spaces. Personally I don't care if it is a
four-space tab or four spaces, but definitely not 8 spaces although some of
that did get in there.
> - include: It is not my personal style to use includes in the SDK,
> however: Wouldn't it be good if we moved them to classes not named
> "*.as" but rather "*.as.inc"?
Includes should only be in two places: version.as, and some interfaces that
mirror some flash.display.* classes. I don't think any of the latter
includes are used more than twice, so it might be simpler to just copy and
paste the includes into the files that use them and get rid of the includes.
> - Version.as: What for do we need that included in every class? Isn't
> that a little excessive? What do we gain from it?
It is used to detect if someone mixed classes from different versions (and
didn't get some earlier failure). I want to have a version stamp in each
class. You proposed a compiler change that could eliminate version.as, I
think.
> - Use of if( "" in obj) or if(obj.hasOwnProperty("")) - which is
> recommended?
Way back when, we were told to use if ( "" in obj) for "sealed" classes and
hasOwnProperty for dynamic objects. The documentation doesn't say that and
I haven't tested speed. And, hasOwnProperty must be used in some prototype
inheritance cases.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui