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.
Mike
Quoting Alex Harui <aha...@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" <m...@teotigraphix.com> wrote:
Quoting Alex Harui <aha...@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
