Nikhil Kothari's Weblog : Script# Update

Finally, an updated Script# build. Woohoo!

Its been all too long since the last update, leading folks to wonder if the project is still alive. I liked to think that the project had simply reached a temporary plateau of a stable release that was functional and usable for a core set of scenarios. Indeed some of the largest Ajax applications at Microsoft like the Office 2010 Web Applications and many others are now built from C# source code compiled to JavaScript, helping large teams of engineers work everyday with large codebases over the course of long product cycles. However, what I am learning is that it is also essential to continually have some set of updates to ensure there is sign of life and progress.

So this post will provide an update of where things are at. First and foremost, the project is by no means dead. In fact the interest level in the project has only just picked up a bit.

Build 0.5.5.0

This is mostly a bug fix release, but there are some interesting fixes, and a couple of small changes. I'll list a few notable ones (the release history page has more details).

Removed the $ shortcut, which was conflicting with prototype and jQuery.
Fixes to scriptlet code editor inside Visual Studio so code is no longer truncated (scriptlet code is now persisted as sibling .scriptlet files - eg. Foo.aspx.scriptlet represents the script code-behind for Foo.aspx). Scriptlets only depend on sscorlib.js now (don't depend on ScriptFX framework anymore - first step in making them work more broadly with fewer dependencies)
Fixes to bitwise comparison expressions, and equality/inequality checks
Fixes to release minimization in a variety of scenarios

If you're new to Script#, check out the project site, and the readme. Download the bits and give it a shot. And be sure to check out the samples that get installed as well for more concrete ideas.

If you've been using Script#, feel free to send me more information about what you've built, esp. if it qualifies for showcase material (I need to revamp that), or comments about what you'd like to see. I'll also use a poll from time to time to guage interest and guide future developments. In fact, I've got one now about what sort of IDE support you'd like to see - Visual Studio 2008, 2010, or Visual C# Express? Right now it seems folks most want 2010 support. I wasn't planning on 2010 support until VS2010 was out of beta, but looking at the early results of the poll so far, I've decided to go ahead and add an installer for that in addition. So with 0.5.5.0 you also get 2010 support!

Got questions?

I am planning to use stackoverflow rather than spending time building a dedicated forums. Lets see how that experiment goes, and whether it works out. Simply post your questions tagged with scriptsharp. I'll try to monitor them, and hopefully there will be folks in the community who can also pitch in with their experience.

Next Steps - Build 0.6.0.0 and beyond

The next build will see some bigger changes. This is sort of an heads up. From a functionality perspective you're going to see two things happen:

The MSAjax support will grow to include support for all the new APIs coming out as part of ASP.NET Ajax. Aacorlib.dll (the equivalent of mscorlib) will be called mscorlib.dll (which should make FxCop happy), and MicrosoftAjax.dll will be broken out to match the different individual script files making up ASP.NET Ajax.
The MSAjax mode of script# has been less functional than the native Script# mode (using sscorlib). Using an extension script to add missing functionality on top of the ASP.NET Ajax scripts, in 0.6, the modes will be nearly identical. So if you're using the MSAjax mode, you'll benefit from array instance methods, delegates, ability to use foreach etc.

Beyond 0.6, the list is interesting and long - generics, scriptlets for ASP.NET MVC, jQuery support, polishing up the unit testing infrastructure couple of teams have built, and streamlining the IDE experience etc. etc.

On-going updates and communication

I've been on twitter now for some time, and it makes it much easier for quick updates than the blog posts. As such, I've set up a twitter account for Script# specifically, that I'll use for announcements, quick updates, as well as the direct or brief conversations, and occasionally post a question targeted at Script# users. Follow @scriptsharp to stay up-to-date ... oh and feel free to follow @nikhilk too while you're at it :-).

If you've got a deeper question that isn't suitable for twitter or for stackoverflow-style Q&A, then please use my contact form to reach me. I'll get back as soon as possible.

Enjoy! And if you hit any unexpected issues, do let me know... in case I need to put out an incremental quick fix release...

Posted on Sunday, 11/29/2009 @ 10:19 PM | #Script#

Comments

Erik Källén

Posted on 12/7/2009 @ 4:18 AM

As I'm finding problem phrasing my issues as questions suitable for SO, I give you my thoughts here instead:
Bugs:
* Array.extract() does not support extracting an empty slice by passing 0 as the count.
* A few issues with partial classes:
- If the different partial definitions implement different interfaces, there is a risk that Script# will just die silently.
- The non-debug script doesn't work with partial classes. The issue is that all private variables are replaced with $1 etc, and it seems that each partial definition has the counter reset so different variables will get the same name.
* When different overloads of a method has different return types, the compiler might die when chaining calls (causes quite an annoyance with jQuery, already noted by Robert Byrne).
* IMO, a character literal (e.g. '\n') should be translated to an integer and not to a string in JavaScript. This has bitten me a few times, and I have not encountered a case where the current behaviour works.
* Function.prototype.invoke should return the result of the invokation.

Things I'd love to see:
* I'd love to have a -dont-mess-with-my-case switch that prevents the automatic conversion of methods and variables to camel-case.
* More supported methods on [Record] types (unvaluable for JSON): Instance methods (which would, of course, be translated into static methods with an explicit this parameter), is/as (using duck typing). Btw, I think it is a bug that if you define methods on a Record type, you will not receive an error, but the method will just silently be ignored.
* Support for C#'s var keyword (not that important, but I guess it would be quite easy to implement).
* Interface inheritance.
* [AlternateSignature] on constructors.
* The ability to use fully namespaced type names everywhere. This would really help in code generation scenarios.
* (of course generics, but you already know that, and I guess it's complicated).

Metadata:
* DOMAttributeCollection is missing the item method (index by integer)
* I don't know whether this is a good idea to include, but in JS you can compare strings for less-than, greater-than and such. These operators are not in the metadata.
* TableCellElement is missing the CellIndex property.
* I think that it would be a good idea to be able to index a System.Dictionary by an integer key. I do this all the time: x = dict[(string)(object)intKey].
* This mehtod is incredibly handy when working with jQuery, so I think it should go into sscorlib:
public static Delegate Wrap(Delegate d) {
return (Delegate)Script.Literal("function(){{var x=[this];for(var i=0;i<arguments.length;i++)x.push(arguments[i]);{0}.apply({0},x);}}", d);
}
It allows you to create a wrapping delegate whose this parameter is passed as the first argument to another delegate.

That's it for now. Feels bad to complain, but these are pretty much the only issues I have encountered after working with the product for half a year. And for everyone who reads this: Even with these defects, Script# is the best thing that has happened to web development since Asp.NET 2.0

Kirill Bondar

Posted on 12/25/2009 @ 7:49 AM

@Eric:
* [PreserveCase] attribute should prevent compiler from messing with the name's case.

* Dictionary (JS Object) stores values under string keys. If you pass an object as the key it will be converted to string via .toString() call. So, I think, Dictionary class design is close to reality - and, instead of using type case you can use dict[intKey.ToString()].

@Nikhil
* Dictionary constructor complains if the key does not comply with identifier syntax - but it does not have to. You can simply enclose the key in quotes in this case.

* Array instance methods are the root of evil: they got enumerated in JavaScript for..in statement and this can introduce the problems when using third-party frameworks. I guess, that's the reason MicrosoftAjax.js defines all of Array extensions as a class methods. Moreover, most of Array's utility functions use only indexer and length property and can be used with DOM collections of different sort.

S# compiler could translate some instance methods to static methods with "this" as a first parameter - as it is done for Object.GetType(), or even better, let it be controlled via an attribute - but I guess extension methods are not applicable for this case.

* We were playing with the replacement of the S# core library and it turns out that imported types have limited support generics: while generic classes and interfaces are not supported, generics delegates and methods are:

delegate void Action<T>(T x);

class Array
{
public static void ForEach<T>(T[] array, Action<T> predicate) { }
...
}

The following definition is successfully imported and you can use ForEach() unless you try to specify generic parameter; in most cases compiler can infer it from usage.

As most of DOM node manipulation methods return the same object passed as an argument, they could be defined in the same manner, to save extra typecasts:

T AppendChild<T>(T node)

if only you can specify "where T: HtmlNode" constraint. But as soon as you do it, the S# compiler starts to complain about unsupported feature. Is far as I understand it's more like sanity check - any chance to have it fixed?

Anyway, thanks for the excellent product :)

Script# Update - v0.5.5.0

Comments

Robert Byrne

Marcus Baffa

Jeff Lewis

Edison M. Castro

Nikhil Kothari

Shiva

Shiva

Nikhil Kothari

Robert Byrne

Ernesto

Nikhil Kothari

Erik Källén

Software development india

Nikhil Kothari

Erik Källén

Sergey

Daniel Pamich

Jerry

Kirill Bondar

Bruce

Bruce

Erik Källén

Mark Phillips

parvesh

parvesh