Question
Fx prefix revisited
Alrighty, we promised we'd have further discussion about this on the forums, so here we go. Since I think the email system can't handle really long posts, I'm going to post a series of things that I've written up, along with some responses that started among the team. We'll take things from there.
Solving the naming convention with regard to overlapping classnames is especially difficult when you take a number of factors into account. Here are some of the things to consider as we look to address the issue (not prioritized and not exhaustive):
These issues can be attributed to general use and the SDK:
- 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.
- How does CSS differentiate between classes with the same local name (class name)
- How will new users understand the differences between Spark and Halo classes, and especially understand when there is overlap
- What should documentation do to differentiate between Spark and Halo controls, and how do we control which page a user arrives at when searching
- How will someone reading code easily understand which control the code is using
- Given the change in architectures, how does someone easily know which architecture a component belongs to
- The number of overlapping controls between Spark and Halo will increase after Flex 4, Spark will receive new controls over time
These issues can be attributed to an IDE (any of 'em):
- How does code hinting work when you have overlapping classes (what can it do to help differentiate)
- If a list of components is in a panel, how do those components get differentiated
- Should a tool warn when components from different architectures are mixed, how does the tool know when such mixing of overlapping components or architectures is intentional
- Should the tool promote one architecture's components over another, or provide user preferences to control promotion, and how flexible do those preferences need to be
Next up: the current situation.
Solving the naming convention with regard to overlapping classnames is especially difficult when you take a number of factors into account. Here are some of the things to consider as we look to address the issue (not prioritized and not exhaustive):
These issues can be attributed to general use and the SDK:
- 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.
- How does CSS differentiate between classes with the same local name (class name)
- How will new users understand the differences between Spark and Halo classes, and especially understand when there is overlap
- What should documentation do to differentiate between Spark and Halo controls, and how do we control which page a user arrives at when searching
- How will someone reading code easily understand which control the code is using
- Given the change in architectures, how does someone easily know which architecture a component belongs to
- The number of overlapping controls between Spark and Halo will increase after Flex 4, Spark will receive new controls over time
These issues can be attributed to an IDE (any of 'em):
- How does code hinting work when you have overlapping classes (what can it do to help differentiate)
- If a list of components is in a panel, how do those components get differentiated
- Should a tool warn when components from different architectures are mixed, how does the tool know when such mixing of overlapping components or architectures is intentional
- Should the tool promote one architecture's components over another, or provide user preferences to control promotion, and how flexible do those preferences need to be
Next up: the current situation.
AdChoices