Evolution of the Dance
30-Oct-06
Yeah, so maybe I’m way behind the rest of the population in seeing this, but…wow…this guy is amazing and hilarious. Funniest six minutes of my life.
At least recently.
Multiple Interfaces
26-Oct-06
Had a thought: how do people handle mutually exclusive interfaces?
I suppose there's no such thing as mutually exclusive interfaces from a code perspective, but from a logic perspective, there may be. For example, let's say you do one of two things based on whether a class implements one of two interfaces. What do you do if something implements both?
Lousy code:
-
// IAmChocolate.as
-
interface IAmChocolate { ... }
-
-
// IAmNotChocolate.as
-
interface IAmNotChocolate { ... }
-
-
// Candy.as
-
class Candy { ... }
-
-
// ConfusedCandy.as
-
class ConfusedCandy extends Candy, IAmChocolate, IAmNotChocolate { ... }
-
-
// Application.as
-
class Application
-
{
-
public static Main() : Void
-
{
-
var candy:Candy = new ConfusedCandy();
-
if( (IAmChocolate(candy)) != null )
-
{
-
// do something
-
}
-
else if ( (IAmNotChocolate(candy)) != null )
-
{
-
// do something else
-
}
-
}
-
}
Yes, not great code, and I suppose the logic could be to not use an else if, but that will depend on what needs to be done. Really, I'm thinking more at the library/API level - for a distributed library, what do you do when you have one Interface that should not be combined with another? The only real solution that comes to mind is to use classes in those cases instead of libraries, but...
Ok, really, the answer is probably to avoid the situation. Considering I haven't come up with a real scenario where this would be a concern (I'm thinking about it, though).
One of the things that I'm thinking about is .NET Generics, which allow you tell a Type argument that it must bind to a class or interface (eg: for a given Type argument, it must extend a given class or implement a given interface to be passed as an argument to the Generic class/method). But that's the opposite situation - and obviously doesn't map to Actionscript at all (not that this is exclusively an Actionscript question, because it most definitely is not).
I realize this is probably pretty esoteric, but...Any ideas?
|
flash.jsfl |
| Browse Archives at groups.google.com |
One of the neat things about the ASP.NET Page class is the RegisterClientScriptBlock method (the RegisterStartupScriptBlock is also cool, and this here tip applies just as well to it). What the RegisterClientScriptBlock method does is add whatever script you pass to it to page, and register it with a key, such that a script is only added to the page once (assuming you only want it added once). The signature for the method is:
-
public void RegisterClientScriptBlock( string key, string script );
Ok, wait. I missed something. Damn.
It seems that in ASP.NET 2.0 this method is obsolete, replaced with the [Page.]ClientScript.RegisterClientScriptBlock method (Page.ClientScript is an instance of ClientScriptManager, nice little refactoring for you...), signature as follows:
-
public void RegisterClientScriptBlock( Type type, string key, string script );
[Actually, there's a bunch more that the ClientScriptManager class does (well, instances of said class, anyway) - more info on the msdn]
What I was going to say is that it always irks me coming up with a key for the script block. And using the Type as the key makes a bit of sense (until, of course, you get into multiple script blocks being registered from a single page, control or Type). Regardless, it could be used as a base, eg:
-
protected void InitializeScripts()
-
{
-
Page.RegisterClientScriptBlock( GetType().ToString(), @"<script language=""javascript"" type=""text/javascript"">function foo() { return ""bar""; }</script>" );
-
}
And then, bam! - you wouldn't have to think about it, and there'd be very little chance of name collisions. Which is, I assume, why the engineers of the BCL (particularly the System.Web namespace) refactored the method - the key gets duality (between the Type passed as well as the string key), and hence very little chance of name collisions.
I'm sitting through Fritz Onion's workshop on ASP.NET development, and I noticed he was using GetType() in the RegisterClientScriptBlock. I neglected to notice that he was not calling it directly on the Page object (rather, on the ClientScript property of the Page object). It's a good thing I'm so thorough and checked the method signature, saw the obsolete attribute, and gave you all the real deal. Nevertheless, if you're still coding ASP.NET 1.1, it's not a bad option.
Of note is that it would have been cool if they had added the ClientScript property to the Control class, as a shortcut to the Page's ClientScript property. Not absolutely necessary, I suppose, but I think it's a bit cleaner to have:
-
class MyControl : System.Web.UI.Control
-
{
-
// ... blah ...
-
-
protected void InitializeClientScript()
-
{
-
ClientScript.RegisterClientScriptBlock( GetType(), "jsMethodDeclarations", @"<script>function blah() { return ""blah blah""; }</script>" );
-
}
-
-
// ... blah ...
-
}
...instead of (replace line 7 above with this):
-
Page.ClientScript.RegisterClientScriptBlock( ... );
[note: the latter method works - the former doesn't.]
Though I suppose there are reasons for that (for example, since Page extends Control you would end up with some ambiguity, as the Control class has a Page property, which, in the Page class, references the Page, which would mean they would have to override ClientScript in the Page class, which makes no sense. And, as you know, I'm don't believe in ambiguity. Unlike the sentence just before the last one.
Over'n out.
There’s Nothing Like Ambiguity
24-Oct-06
How many countries do you know with criminal records? Note to self: always proof your copy, and try to limit the number of possible interpretations (particularly the wrong ones).
VSLive Boston
24-Oct-06
While some of you are enjoying the weather over at MAX06, I'm in Boston taking in some .NET goodness at VSLive. Just getting started with a workshop this morning, but so far it's looking like a good place to be.
Got in late last night, did not get enough sleep, and could really use a coffee.
If you're at the conference or in the Boston area and want to hang out, drop me a line - jason at jasonnussbaum dot com (email or msn).
Hot Off The Press: FlashDevelop 2.0
05-Oct-06
The team over at FlashDevelop has released FlashDevelop 2.0, final. w00t!
To me, FlashDevelop is pretty much the best open source, free Actionscript Editor. Some features: MXML/AS3 support, project panel, Code-completion, syntax hilighting, snippets, etc.
Work on FlashDevelop 3.0 is well underway, as well. Here's looking forward to that.
Check it out NOW @ FlashDevelop.org