What features to cut for round 2

[Tridus]

Huh!  That is fascinating on System.Addin.  I'm not sure when that was added, but I'm pretty sure it's not in the version of mono we're using.

Reminds me of a Thing I tried to do once only to find out Unity uses .NET 3.5 and the feature I wanted was from .NET 4 (generics with covariance and contravariance).

It's hard to even know what unity supports.  They're using Mono 2.x, whatever that means in terms of direct correlation.  It's close to .NET 3.5, but not fully there.

Heck, .NET 3.5 is still to me "new stuff" in some way, and I have a mistrust of LINQ and view generics as this semi-new thing.  I feel like an old fogey now, but I came into .NET when it was just finishing up beta, and struggled through the painful C# 1.0 period.  The 2.0 revolution that added generics and so on was like a magic gift that I still somehow don't think of as having been around for a long time.  Anonymous methods and even moreso the var keyword and default parameter values are like some sort of black magic to me.  It takes me a while to trust them, because I always have to check heap stasis and I typically want to know if it has the same sort of overhead that virtual methods do versus abstract or standard ones, etc.

Can you believe I still cringe at the extra slight processing of virtual methods?  That was relevant in the very early 2000s when a processor was single core and 800Mhz, but even then it was a little on the fussy side (to put it mildly).  Now it's just a ridiculous thing to even consider, but old habits like that die hard. 

The funny thing about var is that ReSharper actually complains if you *don't* use it, by default. 'string x = "abc";' will make it ask you why you're not using var.

We're mostly working on .net 4.5 now at work and there's so many things available that you almost have to come up with a subset that everyone understands, otherwise it gets unwieldly. Linq made the cut, though, because being able to query a List<T> with that syntax is just lovely.

[jenya]

the var keyword does not affect runtime performance, compiler will infer the correct type at compile time
http://stackoverflow.com/questions/356846/will-using-var-affect-performance

[Draco18s]

the var keyword does not affect runtime performance, compiler will infer the correct type at compile time
http://stackoverflow.com/questions/356846/will-using-var-affect-performance

While true, it actually makes writing code less strict.  Having gotten into the habit of typing my variables, I like knowing what type they are, and I like my IDE knowing too.

[x4000]

sendmessage, quick google scan says this is reflection and could be bad
https://www.sebaslab.com/whats-wrong-with-sendmessage-and-broadcastmessage-and-what-to-do-about-it/

Color me not surprised. :/  Another case of unity doing something in a really convenient fashion but choosing a rather stupid implementation for it.

the var keyword does not affect runtime performance, compiler will infer the correct type at compile time
http://stackoverflow.com/questions/356846/will-using-var-affect-performance

While this may be true, I don't trust that is is true in the case of Mono.  The version of Mono used in unity is janky in a number of ways -- foreach causes heap allocations!!  When we moved over from native .NET to mono, there were a number of things that had been perfectly great in performance that suddenly were disasters on the CPU or RAM or GC or all of the above.

Not to mention the GC itself is really really bad.

the var keyword does not affect runtime performance, compiler will infer the correct type at compile time
http://stackoverflow.com/questions/356846/will-using-var-affect-performance

While true, it actually makes writing code less strict.  Having gotten into the habit of typing my variables, I like knowing what type they are, and I like my IDE knowing too.

This, too.  There are plenty of cases where type can't be correctly inferred, too.  Is an integer-looking number an int32?  uint?  Int64?  Etc.  A lot of times that doesn't matter, but sometimes it does.  And I don't really care for having all my integers defaulting to 64bit just because we're on a 64bit system; frankly short and ushort should be used a lot more than they are.  And actually I guess that really should be int16 and uint16; I don't know if short got remapped to int32 on 64bit machines.

And a lot of times that will vary by machine and compile parameters.  If you're hoping for sim-concurrence in a game that can desync, then even float isn't precise enough thanks to differences in FPUs; there are cases where you can get away with it by using a double, but in general we use fixed-int math instead for the ultimate in predicability (and bitshifts are handy with that, too).

It's a funny mess, the ecosystem of various implementations of the .NET spec...

[Draco18s]

This, too.  There are plenty of cases where type can't be correctly inferred, too.  Is an integer-looking number an int32?  uint?  Int64?  Etc.  A lot of times that doesn't matter, but sometimes it does

Or in the monster of a method signature I wrote yesterday:
(Java)

private <T extends Comparable<T>, V extends T,U extends Comparable<U>, W extends U> void addArbitraryOre(String orename, IBlockState flower, IBlockState desertFlower, @Nullable IProperty<T> flowerProp, @Nullable V flowerValue, @Nullable IProperty<U> desertProp, @Nullable W desertValue) { ... }

Technically I could shorten the generics to <T extends Comparable<T>, U extends Comparable<U>> and remove the @Nullable annotations, but given the method I pass these parameters to (and isn't mine) uses "V extends T" I figured I should match.  This was just an internal helper method anyway.

But using "var" would be too dangerous.

[Tridus]

While this may be true, I don't trust that is is true in the case of Mono.  The version of Mono used in unity is janky in a number of ways -- foreach causes heap allocations!!  When we moved over from native .NET to mono, there were a number of things that had been perfectly great in performance that suddenly were disasters on the CPU or RAM or GC or all of the above.

It has to be true, it's how var works. var doesn't exist in the runtime, the compiler figures out what it is and makes the IL code for that. Mono could derive something weird, I guess, but it has to derive *something* at compile time. Thus, there's no performance cost there.

This, too.  There are plenty of cases where type can't be correctly inferred, too.  Is an integer-looking number an int32?  uint?  Int64?  Etc.  A lot of times that doesn't matter, but sometimes it does.  And I don't really care for having all my integers defaulting to 64bit just because we're on a 64bit system; frankly short and ushort should be used a lot more than they are.  And actually I guess that really should be int16 and uint16; I don't know if short got remapped to int32 on 64bit machines.

And a lot of times that will vary by machine and compile parameters.  If you're hoping for sim-concurrence in a game that can desync, then even float isn't precise enough thanks to differences in FPUs; there are cases where you can get away with it by using a double, but in general we use fixed-int math instead for the ultimate in predicability (and bitshifts are handy with that, too).

It's a funny mess, the ecosystem of various implementations of the .NET spec...

Can you even do that in C#? I know if I do this:

var x = 14;

It's an int. The spec says so. It's *always* an int, unless it can't be represented as an int. The only other way it's not an int is if I tell it otherwise:

var x = 14L;

That one would be a long. There is, oddly, no way to do this for a short. But unless there's a button somewhere I haven't seen in C#, someone can't come along and change what "int" means, which means var is very consistent in what you get out of it.

Or in the monster of a method signature I wrote yesterday:
(Java)

private <T extends Comparable<T>, V extends T,U extends Comparable<U>, W extends U> void addArbitraryOre(String orename, IBlockState flower, IBlockState desertFlower, @Nullable IProperty<T> flowerProp, @Nullable V flowerValue, @Nullable IProperty<U> desertProp, @Nullable W desertValue) { ... }

Technically I could shorten the generics to <T extends Comparable<T>, U extends Comparable<U>> and remove the @Nullable annotations, but given the method I pass these parameters to (and isn't mine) uses "V extends T" I figured I should match.  This was just an internal helper method anyway.

But using "var" would be too dangerous.

My Java is rusty, but I'm pretty sure using var would be a compiler error there, because it returns void. There's no type for var to infer.

[keith.lamothe]

It has to be true, it's how var works. var doesn't exist in the runtime, the compiler figures out what it is and makes the IL code for that. Mono could derive something weird, I guess, but it has to derive *something* at compile time. Thus, there's no performance cost there.

Yea, it's like extension methods where it's all compile-time, so it's safe enough.

We're just grognards about everything being strongly typed, not just at runtime, but in the mind of someone reading the code..

But unless there's a button somewhere I haven't seen in C#, someone can't come along and change what "int" means

We've generally assumed that int is an Int64 in a x64 project. Apparently we were incorrect: http://stackoverflow.com/questions/651956/sizeofint-on-x64

I'm occasionally pedantic enough to write Int32. I almost always write "Int64" over "long".

[Draco18s]

My Java is rusty, but I'm pretty sure using var would be a compiler error there, because it returns void. There's no type for var to infer.

I meant for the method parameters.

But sure, I'll give you a var a = method() example.

public <T> T getCapability(Capability<T> capability, EnumFacing facing)

Enjoy.

[garion333]

Hey all! I'm here to discuss what features to cut add in as Stretch Goals!

*reads thread*

[Tridus]

My Java is rusty, but I'm pretty sure using var would be a compiler error there, because it returns void. There's no type for var to infer.

I meant for the method parameters.

You can't use var for method parameters. Someone realized that'd be an unfortunate idea.

But sure, I'll give you a var a = method() example.

public <T> T getCapability(Capability<T> capability, EnumFacing facing)

Enjoy.

eew

[x4000]

But unless there's a button somewhere I haven't seen in C#, someone can't come along and change what "int" means

We've generally assumed that int is an Int64 in a x64 project. Apparently we were incorrect: http://stackoverflow.com/questions/651956/sizeofint-on-x64

I'm occasionally pedantic enough to write Int32. I almost always write "Int64" over "long".

WHOA!  This changes a whole lot of things, in my opinion.  Heck, we might be able to support 32bit OSes after all with AI War 2.

I recall super distinctly reading that int changed what it was aliasing at some point.  It may have been misinformation, or maybe it was java or something.  It looks like ILP64 does do that, but .NET doesn't use it, so hooray.

Given that our simulation runs entirely on int and long and does not use float in anything deterministic, that means we'd be okay with cross-compatibility between 32bit and 64bit clients.

[Tridus]

Maybe you were thinking of IntPtr, which does change size?

[Mad Rubicant]

I don't recall where I read this, but

Code: [Select]

byte ::= (unsigned 8-bit) Byte
short ::= Int16
ushort ::= UInt16
int ::= Int32
uint ::= UInt32
long ::= Int64
ulong ::= Uint64

And then there's IntPtr which is probably a wrapper around a machine pointer, which does vary with architecture. AFAIK on x86 it's always 4 bytes and x86-64 it's always 8 bytes. This also has the interesting effect of screwing you over when you use ints to index arrays in 64-bit mode C/C++, because the compiler sees a type mismatch (Array dereference is a 64-bit pointer, but you're adding a 32-bit value to it) and generates less-performant code in the 99% of cases where you're not relying on your index being a 32-bit int.

[Draco18s]

But sure, I'll give you a var a = method() example.

public <T> T getCapability(Capability<T> capability, EnumFacing facing)

Enjoy.

eew

That's actually the upgraded version of "MyTileEntity extends TileEntity implements [list of 29 interfaces]"

The interface lists were stupid huge and required @Optional annotations so that said interfaces were removed if the mod they were for wasn't present.  Now its all handled by capabilities.  You ask it for what kind of capability you want, and you get it back.[/list]

[x4000]

Apparently it was IntPtr I was thinking of, I guess. I don't know, I guess this is a misconception I've had for coming on a decade and a half.