toJSON on par with toString

[juan_gandhi]

I've been thinking lately... say, you are writing a pojo, and it is a good practice to have a good toString(), right? How about toJSON/fromJSON? seems like it would be a good idea to have it everywhere as well, what do you think?

Comments

[cema.livejournal.com]

I think positively.

[selfmade.livejournal.com]

In C# we have extension methods - special static methods declared separately, but used as regular methods, pretty much like prototype methods in javascript.

public class MyClass {}

// declaration
public static class Ex
{
  public static string toJson<T>(this T obj) { /* serialize to json */ }
}

...

//usage
var myobj = new MyClass();
myobj.toJson();

[ivan-gandhi.livejournal.com]

I know c# is a more advanced language than Java.

We have "extension methods" in python, in scala, in javascript...

[xeno-by.livejournal.com]

Tho Java has one thingie I crave for when programming in C#. Static imports. They have much more limited area of use than extension methods, but in the cases of applicability they just rock.

[wizzard]

btw is there a way to access the extension methods using reflection (maybe using custom binders or something?)

afaik they have some special attributes applied to them, so i can search for them, but i wonder if this functionality is available through the usual means

[xeno-by.livejournal.com]

Extension methods are plain static methods, they just have the [ExtensionAttribute] annotation. You can invoke them as regular static methods - there's no semantic difference encoded in IL.

[wizzard]

I mean, to resolve them through GetMethods on type specified with 'this' modifier in code :)

[xeno-by.livejournal.com]

This won't work. When desugaring extension invocations compiler knows about lexical context - current namespace and the list of "usings". When you perform late binding, you don't have such info.

There are several workarounds tho, but they depend on your particular business logic. E.g. you could hardcode namespaces to look extension methods in (via compile-time constants or via configuration). Another option would be reading PDBs and acquiring namespace info for the method you wish (tho this won't work for release builds). Well, you get the idea - all solutions to this problem are hacks that work only under certain circumstances.

Btw, because of this particular glitch DLR doesn't support extension methods.

[wizzard]

I see. Maybe they'll encode it in IL at some time.

[xeno-by.livejournal.com]

By the way, this stuff with extension methods is a part of a global problem with C# 3.0 innovations. When used within LINQ scenarios, they play well and seem to be orthogonal additions to the language. But take a step aside - and you face all the ugliness.

[wizzard]

hehe. c# 2.0 was basically a direct mapping to CLR capabilities, but c# 3.0 went beyond that, that's why the discrepancies

[selfmade.livejournal.com]

http://www.hanselman.com/blog/HowDoExtensionMethodsWorkAndWhyWasANewCLRNotRequired.aspx

[smalgin.livejournal.com]

yes yes yes yes