Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4F4752BB.20204@leichtgewicht.at>
Date: Fri, 24 Feb 2012 18:04:59 +0900
From: Martin Heidegger <mh@leichtgewicht.at>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: flex-dev@incubator.apache.org
Subject: Re: [CODE] Short cleanup
References: <CB6C8408.3C88F%aharui@adobe.com>
In-Reply-To: <CB6C8408.3C88F%aharui@adobe.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.