flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Om <bigosma...@gmail.com>
Subject Re: Falcon location
Date Wed, 15 Aug 2012 19:18:32 GMT
On Wed, Aug 15, 2012 at 11:44 AM, Omar Gonzalez

> >
> > IMO, you are arguing against the principle of modularity and/or
> separation
> > of concerns.  Yes, there is a bit more overhead, but is should be worth
> it.
> > You voted for a much more complex branching strategy supposedly in favor
> of
> > modularity.  I'm surprised you are pushing back on it here.
> >
> > --
> > Alex Harui
> > Flex SDK Team
> > Adobe Systems, Inc.
> > http://blogs.adobe.com/aharui
> >
> >
> This ^^^.
> -omar

I am sorry if I sound like I dont support modularity.   But that is not
what I am saying here.  By Gordon's (who is probably the only person on
this list who knows the Falcon codebase) own admission, Falcon is tied
closely to the Flex framework because of the semantics of MXML.  I agree
that this is not a good thing. I agree that this should be changed.

But, until that level of separation is achieved, how can I as a developer
make sure that Falcon works with the current sdk that I want to ship in the
next release?

I keep seeing the word 'eventually'.  All I am saying is, in that eventual
case, lets make Falcon a top level project.  There is nothing preventing
anyone from modularizing and separating the concerns of Falcon while still
under modules/falcon.  But the other way round, making Falcon a top level
project prevents me from working with it in the short term.

> Yes, there is a bit more overhead, but is should be worth it.

How do we know if it is worth it if we don't know what exactly the overhead
is?  No one has proposed a workflow to working with Falcon as a top-level
project yet.

Whereas, I am proposing a workflow which is to keep Falcon under modules
and create a separate branch where this would be the main feature.  Anyone
who wants to work with Falcon can simply switch to that feature branch.
Convince me why this is not a better idea.  The only reason against it so
far is: "it will be confusing".  Why is this confusing?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message