I read an article in SD Times that talked about how Microsoft (and .NET) does not support dynamic, or scripting languages as much as it should. First, let me say that I think scripting languages can be powerful when you need a severe amount of flexibility during run-time. Second, let me say that most applications don't need this sort of flexibility. And, while it could be handy for anyone, I don't know that it's an all-encompasing solution.
Either way, I was thinking about how someone could implement some of the features mentioned in this article. One was that you cannot call static methods without specifying a class that the methods belonged to. I see this as a good and bad thing, I guess. First off, I have to say that it is a good thing because you know where everything is located and/or who owns it. If I see Convert.ToString(), I know that this can be found in the System.dll assembly, the System namespace, and the Convert class. Hopefully, my documentation and software practices can guide me the rest of the way to get what I need updated/done. On the other hand, I must admit that it would be useful to have a few custom functions that could be called at any time - this was most definitely useful in my ASP/VBScript days. For instance, a non-cryptic if-then-else statement would be very nice. For instance, Oracle has a Decode() function that can be called from PL/SQL (Oracle's version of T*SQL).
SELECT
DECODE( COUNT(*),
0, "Nobody likes you!",
1, "You know your mom doesn't count, right?",
"Wow, you have friends!? I'm surprised." )
FROM friends;
This function basically takes the effect of Decode( ifThis, equalsThis, thenThis, elseThis ), where the equalsThis and thenThis parameters can be repeated any number of times (there may be a limit, I'm not sure).
Anyway, this is just one example that I'd like to see. I'm sure that in your ventures with strings, you have come up with at least two or three custom methods that you like - StripHtml(string) is another one. Maybe this is just my old scripting self wanting some of this back, but it does seem like there's no true place for some of these functions. One answer would be to extend the String or StringBuilder classes, but that doesn't make sense, if you think about it. We get used to these reusable code sets. When we are without them, we sometimes forget how to do what it takes. I'm not sure how many people created database connection classes in VBScript, but let me tell you that every application I wrote used mine. And, I completely forgot how to work with databases. When I was stuck without it, instead of re-learning it, I was on the phone for an hour trying to get a hold of someone who I knew could get it to me. Whether my example is worth it or not, you get my point.
Another answer to creating these functions, which seems to be the best in my opinion (at least form an OO point of view), is to create a utility class. For instance, StringUtil.StripHtml(string).
Knowing this approach seems to work best for me, I thought about what it would take to have the equivalent of functions in .NET. Perhaps allowing a namespace to have its own default utility class would solve the problem. I don't know if I'd advise this practice, since it might be hard to map the use of a function to a particular namespace utility, but it seems feasible. Here's an example...
using
System;
namespace Indigo
{
public class IndigoUtil
{
public static object Decode( object ifThis,
object equalsThis, object thenThis )
{
Decode( ifThis, equalsThis, thenThis, ifThis );
}
public static object Decode( object ifThis,
object equalsThis, object thenThis, object elseThis )
{
if ( ifThis.Equals(equalsThis) )
return thenThis;
else
return elseThis;
}
public static string StripHtml( string html )
{
...
return html;
}
}
}
Then, in your class, you would do the following...
using System;
using System.Web.UI;
using System.Web.UI.WebControls;
using Indigo;
namespace
Indigo.Examples
{
public class UtilTestPage : Page
{
private void Page_Load(object sender, System.EventArgs e)
{
...
string strText = StripHtml(MessageBody.Text);
...
}
}
}
The compiler look for the StripHtml(string) method within the current class, not find it, then look for it in the Util classes for each respective namespace that is included the class file. In this case, that would be System.SystemUtil, System.Web.UI.UIUtil, System.Web.UI.WebControls.WebControlsUtil, and Indigo.IndigoUtil. As you can see, if you have a lot of namespaces included, this could take a while. And, if there were conflicts, you would just have to specify the specific Util class you're referring to. For instance, if a new version of .NET had a StripHtml(string) method in the WebControlsUtil class, then I would just have to specify IndigoUtil.StripHtml(string) instead.
This seems like it would take care of the function problems that are mentioned in this article, but the next step is to make calling dynamically-determined methods easier. I still remember and miss the Eval(string) function. Of course, we could always implement System.Reflection.ReflectionUtil.Eval(string), but behind the scenes, that might be a hefty job to pickup. We'll see if anyone *cough, cough* Microsoft *cough, cough* picks this up (hint, hint; nudge, nudge).