Compile-time error with Nullable DateTime / user Enumeration.

[duckmaestro]

I'm receiving a set of compile-time errors when trying to declare DateTime? or MyEnumType? as method parameters.

Example (for one occurrence of public DateTime GetServerTime(DateTime? clientTime) { ... }:

MySourceFile.cs(62,48): Syntax error: 'Identifier' expected
MySourceFile.cs(62,60): Syntax error: ':' expected
MySourceFile.cs(62,48): Syntax error: Expression statement must do work
MySourceFile.cs(62,60): Syntax error: ';' expected

I have a workaround for now (using pre-0.7.x technique). This is just FYI.

[mattclay]

I'm having the same problem with 0.7.2. Adding a nullable DateTime field to a class as follows will fail to compile:

DateTime? x;

It results in the following compile errors:

Syntax error: 'Identifier' expected Syntax error: 'Identifier' expected

Changing to the following allows it compile:

Nullable<DateTime> x;

[nikhilk]

DateTime should probably not be a value type in script# so it correctly reflects script semantics.

[mattclay]

I agree that DateTime should not be a value type in Script#.

Although it is nice to have types in Script# that closely match .NET types, it is more important they accurately reflect their respective types in JavaScript as much as reasonably possible.

[Ventajou]

One thing I like about Script# is the ability to declare a class in my server side code and add a link to it in my Script# project. This makes it easy when sending data back and forth through web services.

Having to use two classes because Script# won't match c# types would add some unnecessary complexity.

[nikhilk]

I agree that is an interesting scenario ... however script# was never intended to cater to the cross-compilation/porting scenario, though if you tread carefully, you can get a bit lucky (sometimes) :-)

As Matt Clay mentioned, my first preference would be to honor script semantics, and a date in script doesn't behave like a value type. That said, my hopes of converting DateTime to be a class were squashed, because the c# compiler doesn't like it when I try to compile mscorlib itself.

I might still evaluate some alternative like even call the class Date instead of DateTime (if it works) ... but there are pros/cons to that as well. Pro because it will clearly indicate this class isn't behaving like the DateTime value type you're used to in c#, and con because of deviations from core framework constructs. However there are probably enough differences on the date type that the alignment is superficial ... just at the naming level. For example, I believe month is 0-based in script and 1-based in managed code... or some such difference. In that case, a different name altogether might actually be beneficial, even if painful and a bit annoying.

Thoughts on this debate I'm having in my mind?

[duckmaestro]

I tend to do a lot of code sharing lately between Script# projects and server-side .NET projects, as well as w/Unity3d's C# support. Most of my sharing is with auto-generated "packet" classes I make for easier JSON dealings, but I do also share a lot of utility code, math code, and "global" shared constants as well.

I've listened to all points made, and my opinion has actually shifted since what I used to prefer. Long story short, given the differences between JavaScript Date and .NET DateTime, I strongly prefer now the idea of renaming Script#'s to Date and having it map as closely as possible with JavaScript's Date object.

I already create dummy/wrapper classes in a few places simply for convenience in the build processes and to avoid cluttering up code with #ifs everywhere. If Script# DateTime is renamed to Date, I'll simply in a similar fashion make a new dummy/wrapper class (if needed) called DateTime, and on the net whole I think I'll benefit from the added clarity and reminder that when I see Date it's the JavaScript/Script# contract, and when I see DateTime it's the .NET contract.

[nikhilk]

Change made. https://github.com/nikhilk/scriptsharp/commit/6e8d8059d66e9b1cf6e4c206f2bd7625db04ff43