JScript .NET Classes Are Serializable -- Surprise!

You learn something new every day in this job. Or, more accurately, some days you learn things again that you'd forgotten years ago.

Someone just asked me why it is that all JScript .NET classes are serializable. I admit it, my first reaction was "They are?" But I checked the sources, wrote some code and ran it through ILDASM and sure enough, all JScript .NET classes ARE serializable!

Though I did not write that code, surely I must have known that at some point. Now that I think about it a bit more, it's coming back to me. I think the idea was that the designers anticipated that there would often be situations in which JScript.NET objects would have to be passed across appdomains. (Exceptions for instance -- in JScript, you can throw anything.) That means either making classes marshal-by-ref or serializable, and apparently we picked serializable.

We could of course have gone the other way, and made developers figure out which classes needed to be serialized, and defaulted to “not serializable“. But one of the major JScript .NET design principles is "just get it done, already!" C# was designed so that most of the defaults limit behaviour -- things are private until made public, and so on. In JScript .NET, as much as possible is left open; if you want to tighten it up, you go right ahead. This is in keeping with the scripty nature of the language, while still recognizing that people do write large programs in script languages.

If for some reason you wish a class to be not serializable then you can do this:

    public System.NotSerialized class MyClass {

(Notice that in JScript .NET, you don't need to put ugly brackets around attributes. The parser is smart enough to figure out that there is an attribute before the class declaration. However, this significantly complicates the parser; I see why C# and VB.NET require their delimeters.)

Offhand I don't see anywhere on MSDN where this feature is documented, though it is possible that my google-fu has failed me.

Comments

• Anonymous
  May 26, 2004
  In addition, JScript has reflection down to source-code level:
  
  function DoSomething() {
  WScript.Echo('hello');
  }
  
  WScript.Echo(DoSomething.toString());
  
  
  - a feature that's missing from JScript.Net
• Anonymous
  May 26, 2004
  Please forgive my cargo-cultism: What is the difference between Marshal By Reference and Serialization?
• Anonymous
  May 27, 2004
  Dude, cargo-cultists never stop to ask themselves "hey, how exactly DOES an airplane work?" That's what makes them cargo cultists, because they don't ask questions about what they don't understand.
  
  The answer is a little long. I'll write a blog entry on it.
• Anonymous
  May 27, 2004
  JScript .NET supports that in both slow and fast mode -- but not for functions inside classes ("methods"). Either write the function outside of a class, or mark it "expando" to make it old-style:
  
  class c
  {
  expando function p()
  {
  print("Hello")
  }
  
  function q()
  {
  print("Hello")
  }
  }
  
  var x = new c
  print(x.p.toString())
  print("---")
  print(x.q.toString())
  
  
• Anonymous
  May 27, 2004
  Here is an exerpt from a mail I sent to some people on March 20, 2001:
  
  -----
  Currently we always mark classes in JScript as serialisable (since there was no way for the user to specify it). Now that we have support for attributes, we can reverse this decision, but we're not sure if we should. Given that JScript gives users the least-barrier approach to programming (eg, all members are public by default), it seems that marking everything serialisable by default would be a reasonable thing to do.
  -----
  
  So as you can see, we initially did it because (originally) you couldn't add the Serializable attribute to a class, and there were some scenarios that required serialisable classes, so we made sure JScript classes were always serialisable.
  
  I actually remember talking to Herman about this and getting it added to the compiler -- what probably happened was that either I came across the limitation via a newsgroup-posting customer or from my own simple script building exercises, OR he uncovered the anomoly during his own testing or playing with C# or through some other cross-language team communication...
  
  Another history lesson (partially) solved! Although unfortunately my quick search didn't reveal any e-mails or bug entries or newsgroup postings asking for the original change to be made; it was probably just decided in Herman's office one day :-)
  
  
• Anonymous
  May 27, 2004
  Thinking about it a bit more, it was almost certainly so that you could return a JScript object from a web service...
  
  Now I'm really going to go to sleep (it's 3am here...)
  
• Anonymous
  May 27, 2004
  Indeed, I have a copy of that mail in my "JScript .NET Issues" folder, so my conjecture is correct -- I did know that at some point, and forgot.
  
  It's a bummer that you can't selectively clear out memories like you can hard disks. I'd much rather forget the Gilligan's Island theme song than details about the language design, but odds are good that I'll be able to recall "It started from this tropic port..." for the rest of my life.