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.
