April 5, 2006
AS3 -- on the lack of private and protected constructors
As I was talking about using objects as enums, someone made a comment about the lack of private and protected constructors. I know that the this is a sore spot, so I thought I'd explain my view of how we got here, and give my two cents.
The problem is that unlike what we did with ActionScript 2, we are working tightly with people from Mozilla and others to standardize on ECMAScript edition 4. The ECMAScript standard is not final, but we are adhering as closely as we can to the spec as it develops.
Private and protected constructors is not something that the group has been able to tackle yet, and it is a nontrivial change to the language that requires lots of careful thought.
Ideally, we would have been able to think through all the ramifications of private and protected constructors and work with other ECMA members to make sure the design was sound, but that just wasn't possible in the amount of time we had.
Given this, there were three choices:
1) Delay ActionScipt 3 (and Flex, etc.) significantly.
2) Just "go with" a quick and dirty implementation of private and protected constructors for AS3 and risk compatibility problems down the road once the ECMA spec becomes final.
3) Don't allow private and protected constructors for now.
We went with option (3).
The main uses of private and protected constructors are singletons and abstract base classes. In both of these cases, I agree that the lack of real private and protected constructors is a pain. There are hackarounds which will work for now, but I am eagerly awaiting the day when we don't have to use them anymore.
As for the specific use case described in the previous post (using objects as enumerations), the main thing that private/protected constructors allows you to do is to ensure that the set of "enum" values cannot be extended later by someone else.
I personally like having this level of control, but I am willing to live without it. It "feels better" to create a system where no one can add any more values to the enumeration, but in practice,
a) If people create new values for the enumeration and try to use them with code that wasn't expecting those values, it will obviously break. So who is going to do this?
b) If people create new values for the enumeration and use them only within their own code... well... it kind of breaks the spirit of what an enumeration is, but it might be just fine.
Here's a concrete example of scenario (b). Imagine that I create a text control with three values for alignment: LEFT, RIGHT, and CENTER. Someone subclasses this control, and wants to create a fourth enumeration value: JUSTIFY. This new value would obviously only be useful for this person's subclass, but who am I to say that he/she shouldn't create it?
Like I said, I would ideally like the option of controlling what can and can't get extended, but in the case of enumerations, I'm ok with not having that control for now.
Posted by sho at 9:03 AM
March 8, 2006
FAB - Flex / AJAX bridge
FAB - Flex/AJAX Bridge - is a library created by Ely Greenfield, who is a good friend and Flex Architect.
FAB lets you control Flex applications using JavaScript. Method calls just work, and getters and setters are converted to method calls (because browsers don't support getters and setters yet).
You can even attach event listeners from JavaScript and pass function objects back and forth. For example, you can create an MXML file with a button in it and drive all of the logic from within your HTML/JavaScript.
MXML:
--
<mx:Application xmlns:mx="http://www.macromedia.com/2005/mxml">
<fab:FABridge xmlns:fab="bridge.*" />
<mx:Button id="okButton" label="OK" />
</mx:Application>
JavaScript:
--
function init()
{
var flexApp = FABridge.flash.root();
flexApp.okButton().addEventListener("click", handleClick);
}
function handleClick(event)
{
// handle the click event here.
}
You can read more about it on Ely's blog, which I predict will be worth reading.
http://www.quietlyscheming.com/blog/2006/03/06/flex-and-ajax/
Posted by sho at 9:07 AM
March 6, 2006
Slides from Flashforward 2006
As promised, here are my slides and notes from Flashforward. Some things you will need to know:
- The layout syntax uses the new beta 2 syntax, which is not out yet.
- The notes cover a bit less material than the slides. That's because the notes were finalized before the slides were, in order to get them printed on paper for conference attendees. If I have time, I may extend the notes but with so much going on, I am not sure I will have time to do this.
[Speaker notes - doc] [Speaker notes - pdf]
Posted by sho at 1:51 PM
February 24, 2006
Evolution of a feature - layout constraints
We spend a lot of time here on the Flex / Flex Builder team arguing over exactly how each piece of the framework should work, and how the syntax should look.
I thought it might be interesting to have a glimpse into how some of these features evolve, and why. I'm picking a particularly controversial example: layout constraints.
---
Layout constraints came about because designers in particular weren't happy using containers for layout. Actually, let me say it a different way. When you drag things around, they generally expect things to stay put, although they are fine with things moving around when it makes sense (like when you drag something into a control bar). And they want pixel level control over the position of every element.
Among coders, feedback on container based layout was mixed. Most of them "got" it, and some of them loved it. But when you step back, it wasn't good for all layouts. Boxy layouts (think forms) were just fine. More freeform layouts (think Flash) were hard to achieve.
There was also a performance issue. Nesting of containers meant nesting of movie clips. Removing the nesting, however, meant that fluid resizing layouts were hard to achieve.
---
For all these reasons, we decided to add a constraint system to Flex. We originally talked about all sorts of more complex ideas -- sibling constraints and other more exotic constraints -- but we settled the more conservative approach of only supporting constraints relative to the parent container.
Let's say that we want to put a button in the top right corner of our app. Our original syntax looked like this:
Attempt 1:
--
<mx:Panel width="100%" height="100%">
<mx:Canvas width="100%" height="100%">
<mx:layoutConstraints >
<mx:EdgeAnchor target="myButton" right="30" />
</mx:layoutConstraints>
<mx:Button id="myButton" y="30" />
</mx:Canvas>
</mx:Panel>
This would allow us to add new types of constraints in the future, such as sibling constraints. The downside, however, lay in the tooling. Every time you add a constraint to a control, you have to add an ID. If the user changes the ID, you have to change it in both places. It's not rocket science, but it's error prone, and it can lead to situations in which the tool is trying to be "too smart".
We moved the layout constraints to be inside the control itself. This fixed the problem of tracking IDs.
Attempt 2:
--
<mx:Panel width="100%" height="100%">
<mx:Canvas width="100%" height="100%">
<mx:Button y="30">
<mx:layoutConstraints>
<mx:EdgeAnchor right="30" />
</mx:layoutConstraints>
</mx:Button>
</mx:Canvas>
</mx:Panel>
The next issue was that it was confusing to have the canvas inside the panel. People kept accidentally resizing the canvas instead of the panel, or pulling the panel out of the canvas. We also decided that the name "EdgeAnchor" was too verbose.
After much arguing about making things general vs. dealing with the specific needs in the 80% case, we decided to make Panel and Application understand how to do multiple different kinds of layout: absolute, vertical and horizontal.
Attempt 3:
--
<mx:Panel width="100%" height="100%" layout="absolute">
<mx:Button y="30">
<mx:layoutConstraints>
<mx:Anchor right="30" />
</mx:layoutConstraints>
</mx:Button>
</mx:Panel>
Right around this time, people were dragging panels into the view, centering them, and expecting them to stay centered no matter what size the browser was. It was especially confusing because Flex Builder has snapping heuristics and the panel would snap into place when it was centered. We dealt with this by adding a centering constraint.
Attempt 4:
--
<mx:Panel width="100%" height="100%" layout="absolute">
<mx:Button y="30">
<mx:layoutConstraints>
<mx:Anchor horizontalCenter="0" />
</mx:layoutConstraints>
</mx:Button>
</mx:Panel>
Soon after we made this change, the team was busy doing lots of what we call scenario testing: building applications in the same way our customers would. One thing about layout constraints that stuck out like a sore thumb was its verbosity. Where buttons used to be on a single line, they now occupied 5. We argued about this for a while, and decided to make layout constraints styles, partially because this was consistent with CSS.
We also decided to promote the use of "left" and "top" as opposed to "x" and "y". One might wonder how these are different, but they are. The "left" property is a constraint that specifies the desired position for the left coordinate. The "x" property is the coordinate that an object happens to be at. Thus, if you were to use a move effect to move an object programmtically, its "x" property would change, but its "left" would not.
In any case, the resulting syntax looks like this (not in beta 1, but will be part of beta 2):
Attempt 5:
--
<mx:Panel width="100%" height="100%" layout="absolute">
<mx:Button top="30" right="30" />
</mx:Panel>
The moral
--
Why did it take so long to arrive at what appears to be an obvious syntax? Perhaps it was too obvious. When we started, we were trying to solve for many different things: forward compatibility, generalizability, and the possibility of many different kinds of constraints. Through trial and error, we arrived at the simplest way to express the basic things we need for this release.
In this case, I am confident we ended up with the right answer, but it took a while. In fact, there are people out there in the Flash community who aren't convinced that layout constraints are a good idea who I think we will turn around based on the new syntax.
Sometimes, these things take time to sort out. The answers always seem obvious in retrospect, but you can't expect to get to the right answer straight away.
Posted by sho at 9:45 PM