flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Schmalle <m...@teotigraphix.com>
Subject Re: Committer duties and information
Date Wed, 04 Jan 2012 20:57:55 GMT
> I think adding an
> interface here or there and allowing alternate implementations makes
> much more sense than bickering about "which" component should be used.

Let me clear up this statement;

What I meant to say was "give the user" the ability to make alternate  
implementations if their application required it.

I did not mean alternate implementations within the framework. I think  
one component designed well with interfaces has a huge amount of  
customization that can be achieved and I am speaking from years of  
experience with component dev.


Quoting Alex Harui <aharui@adobe.com>:

> Well, it would be best if we could agree on one.  Fewer choices are
> generally better for folks in the learning curve.  Feel free to start that
> discussion at any time.  I took a brief look at your code and didn't see any
> obvious problems with it.   I don't know the Adobe version that well so at
> some point Carol or I can sit down and compare.  I think we might have just
> written our own because we didn't want to deal with the legal issues of
> having more third party code in the Adobe code base.
> And feel free to start a discussion on the use of interfaces.
> On 1/4/12 12:42 PM, "Michael Schmalle" <mike@teotigraphix.com> wrote:
>> Quoting Alex Harui <aharui@adobe.com>:
>> Yes Alex this makes sense. I realize the point of Apache is to be
>> democratic by it's very nature. I wouldn't even think about committing
>> any component like code without a huge discussion on it's impact and
>> value with the community first.
>> I was just trying to get the most extreme case clear in my head.
>> Besides, with something like the TabNavigator, I think adding an
>> interface here or there and allowing alternate implementations makes
>> much more sense than bickering about "which" component should be used.
>> I also think that the list should really have a decent discussion
>> about the future uses of interfaces and the lack of them in the
>> framework to allow for customizations through composition instead of
>> subclassing or copy and paste craziness.
>> Mike
>>> So for practical reasons, I think we're going to start with
>>> commit-then-review.
>>> If you try to commit a new component, that commit will be reviewed and
>>> vetoed out if there is a problem.
>>> So let's get specific.  Let's say you want to contribute your version of a
>>> Spark TabNavigator component.  Adobe has almost finished its version and
>>> promised to commit it.  I would recommend starting a discussion on  
>>> this list
>>> about whether to take yours vs Adobe's.  That way you'll at least have an
>>> idea whether folks are willing to review your version or want to wait for
>>> Adobe.  Then if you do decide to commit, we'll take a harder look at the
>>> code and maybe you'll get rejected if we find some major problem, but
>>> otherwise it gets in.  And if folks want to wait for Adobe and you  
>>> disagree,
>>> you can offer it up under a different package name.  I suppose  
>>> someone might
>>> still try to veto that based on confusing folks about which TabNavigator to
>>> use, so that might be worth discussing up front as well, but I personally
>>> don't have a problems with different flavors of components.
>>> -Alex
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui

View raw message