scriptsharp icon indicating copy to clipboard operation
scriptsharp copied to clipboard

Auto implemented properties

Open alexswan10k opened this issue 11 years ago • 2 comments

Hello,

First let me just say great work so far, awesome tool :)

I have a query regarding auto implemented properties. Currently as I understand it auto properties are not supported but are planned in the future. Properties are currently compiled as two methods for get() and set() and a private backing field which I would assume is also the intention for auto properties. This is all well and good however I have recently found myself getting into a bit of a pickle when doing end to end development. The issue comes from when trying to use the scriptsharp as your goto POCO's. The idea here is that you could use the same POCO from the copiled scriptsharp binary for both persistence of data to a store and serialization over a web service etc as JSON. By doing this you know that wherever you are, the object will be consistent regardless of if it is in the javascript domain or the c# domain (up to a point).

The problem comes from the format of the JSON object. Quite a few popular JSON serialisers (I happen to be using the service stack one currently) only support serialisation of properties. This is all well and good on the server but when I receive the object on the client, i cannot simply cast the JSON object and start using its properties. I have to go ahead and create a new copy of the object due to the scriptsharp compiler attempting to call .get() on the object which of course does not exist. What I would love to see would be finer grain control over how an autoimplemented property is generated/interperated by the compiler, perhaps an attribute that lets you switch between full implementation and a simple field.

I am curious if anyone else has attempted to do anything similar and has found any workarounds though?

alexswan10k avatar Nov 17 '12 17:11 alexswan10k

My thought for auto-implemented properties is that they would be generated similar to how fields are generated, rather than with get/set methods and a backing field. That should take care of your scenario...

nikhilk avatar Nov 17 '12 18:11 nikhilk

That seems to make the most sense to me too. That's good to hear, thanks.

alexswan10k avatar Nov 18 '12 10:11 alexswan10k