It only took me 6 months to reply, but about the time you posted your comment I was recovering from a broken leg and missed a lot of things!

As to using !=, I did mean to use that operator and not *=. Basically, it queries whether the value is undefined or not to generate a Boolean value used in a Switch statement. It’s an unusual way to use Switch as Steven Sacks noted, but it’s a nice clear way to illustrate the structure of the design pattern.

Thanks for your comment,
Bill

… getIntrinsic (key:String, value:* = undefined) …

I think “value:* = undefined” as in “optional parameter named ‘value’ of any type, with default value as ‘undefined’”.

Anyway, very interesting read. Thank you.

However, thanks to your comments, that has been fixed and right at the beginning I make the overlooked reference!

I think that’s the first time I used a switch with a Boolean, and I’m trying to figure out why. At the last OOPSLA meeting in Montreal, we were bombarded with taking out conditional statements for better structure. (The State DP was mentioned as a model for ridding one of conditional statements.) Of course the switch statement is a conditional but didn’t look as much like one, and maybe that was floating around in my head. (Honestly I’m just not sure!)

I really like your idea about the use of the …rest parameter, and I’ll give it a try. As for the conditional using the ternary operator, that too is interesting. In looking at the code, did you mean to use the *= operator or the != operator? If you did mean *=, that I do not understand its use in context and would love to hear how it is employed.

return Flyweight(store.hasOwnProperty(key) ? store[key : store[key] = value)

Your entire getIntrinsic() method need only be one line.

public function getIntrinsic (key:String, value:* = undefined):Flyweight
{
return store.hasOwnProperty(key) ? store[key] : store[key] = value;
}

Cheers!

Bill