On Wed, Aug 15, 2012 at 11:44 AM, Omar Gonzalez <omarg.develo...@gmail.com>wrote:
> > > > 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. Alex: > 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? Thanks, Om
