On 2/23/12 11:32 PM, "Martin Heidegger" <m...@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
