So How Does the Fx Prefix in Gumbo Rub You?
One of the first topics of discussion that the Flex SDK Community Committee addressed was the Fx prefix that is currently implemented in gumbo. We started discussing it here in this thread and during that time adobe opened up the Architecture Review Board notes on the namespaces.
In this mornings SDK Open Iteration meeting the team mentioned they would like to come to a resolution on this matter by the end of the week. So regardless of wether you are for or against the prefix you need to tell adobe how you feel right now. If you feel you have something you want to add please go and comment on the thread for this topic here on Adobes Flex SDK Forum And while I think the item has enough votes because it has been reopened by Adobe please feel free to vote for the bug in the jira site.
Beyond the current Fx issue, I challenge you to open up discussion around the topics you are concerned with by posting them to http://flexsdk.uservoice.com site. This site will allow the Flex SDK Community Committee to know what is important to you and allow the greater community to contribute with one voice to the discussions with Adobe about the SDK.
My main problem with the Fx prefix stem from the first two points Matt pointed out
- Flex 4 aims to be compile-time compatible with Flex 3. This means that we cannot rename existing classes nor break major interface contracts.
- Given we can’t rename existing classes, what package naming structure makes sense if new classes will overlap with existing.
Is Flex 4 and upgrade or not? How can you upgrade without deprecating code? I understand not wanting to overlap naming, but then the legacy components need to have a legacy prefix for the legacy components. The preferential treatment shouldn’t go to old code.
I understand Adobe’s point of view I think. They want to sell Flex Builder 4 to people without hearing complaints about being forced to update their code. I personally think if people want to use Flex 3 they should use Flex 3, if they want to use Flex 4 they should upgrade their code.
I’m sure you wanted me to post that at the other sites, but I don’t think they would even give it a glance. By declaring the initial statement it seems more like they are justifying the Fx prefix than actually looking for a problem.
Hi Garth,
You should feel free to post this to the other sites since we would have responded. I think that if you are building something that claims to be a platform you have obligations to developers who have already committed to your platform that you not break everything. Most programming languages and component sets (think Java and Swing for example) take great pains to not break the contracts that existed previously.
We don’t intend to hamper innovation by being compatible into perpetuity, but I don’t think being compatible for a major release is a bad thing.
Matt
Corrections because blog strips out > and <
What I want to know is, why don’t we just have a new namespace? Have legacy code be < mx:Button > and the new code be < fx:Button > ? Both can live in the same apps, and interop among eachother. I personally do this with my own custom components…. I know I can’t be the only person who thought of this, so there has to be a technicial reason for it.
I fully agree that we shouldn’t break existing code. We don’t want to go in the .NET path and break entire applications between frameworks. We already did that once, and that was hard enough!
editors note: I removed the extra post