10 ms·

Sounds like C# needs destructuring assignment. In Ruby, you're more or less just returning an array that gets destructured immediately -- "return a, b" works th

by djur 13y ago

Sounds like C# needs destructuring assignment. In Ruby, you're more or less just returning an array that gets destructured immediately -- "return a, b" works the same as "return [a, b]".

ufmace 13y ago
Yeah, I thought of that. The trouble is, in Ruby, that works nicely as syntactic sugar because of the dynamically typed nature of the language. Methods have no declared return types, variables also have no declared types, arrays and other data structures hold any kind of object, and you can try and do anything to any variable, and the interpreter will figure out at runtime if that's possible and throw if it can't do it. When you "return a, b", it's clearly an array of objects, since that's the only array Ruby has, and it doesn't matter what the types of a and b are, since the array can hold any type, and the return type is never declared anyways. When you go to use it, you can do "a, b = foo()", which is fine, since you don't have to declare types of variables anyways. You can try and do anything to those a and b after foo, and the interpreter figures it out at runtime. In C#, and I expect Java and most other more statically typed languages, you run into all kinds of awkwardness doing this. Arrays and other data structures are strongly typed by default, and number and type of method returns must be declared. You could return a object[], which is easy enough to declare, but then on the call side, you'd have to declare a object[] to receive the return, then individually cast each element to whatever type it's supposed to be before you can do anything with it. Kinda awkward, and against the spirit of the language. Declaring multiple returns of different types doesn't seem to help much, either, since you can't declare 2 variables of different types on the same line, so you have to declare them both somewhere else, making it about as awkward as using out params. The best solution I can think of that fits with the spirit of the language is to use anonymous types. You can already do: var something = new { Foo = a, Bar = b }; something.Foo.DoStuff(); something.Bar.DoStuff(); In that case, the compiler creates a class for "something" for you invisibly, based on the properties you assigned. What's neat about that is that it maintains strong typing of everything, since it figured out the types from the declaration, so you can still do things with the Foo and Bar properties, and it knows what types they are and enforces all of the standard compile-time type checking. The downside is that you can't return these anonymous types from a method, as the method return type must normally be statically declared. You could return dynamic, but then you lose all of that static type checking, and are back to a slightly cleaner version of returning object[]. I suppose the language authors figured that it's too complex to return anonymous types from methods, as far as figuring out at compile-time what you're actually calling and what it would return. And now that I think I've successfully argued myself out of what I originally wanted to do with a ridiculous number of words, I'll just give up.

by djur 13y ago

Sounds like C# needs destructuring assignment. In Ruby, you're more or less just returning an array that gets destructured immediately -- "return a, b" works the same as "return [a, b]".

ufmace 13y ago

Yeah, I thought of that. The trouble is, in Ruby, that works nicely as syntactic sugar because of the dynamically typed nature of the language. Methods have no declared return types, variables also have no declared types, arrays and other data structures hold any kind of object, and you can try and do anything to any variable, and the interpreter will figure out at runtime if that's possible and throw if it can't do it. When you "return a, b", it's clearly an array of objects, since that's the only array Ruby has, and it doesn't matter what the types of a and b are, since the array can hold any type, and the return type is never declared anyways. When you go to use it, you can do "a, b = foo()", which is fine, since you don't have to declare types of variables anyways. You can try and do anything to those a and b after foo, and the interpreter figures it out at runtime. In C#, and I expect Java and most other more statically typed languages, you run into all kinds of awkwardness doing this. Arrays and other data structures are strongly typed by default, and number and type of method returns must be declared. You could return a object[], which is easy enough to declare, but then on the call side, you'd have to declare a object[] to receive the return, then individually cast each element to whatever type it's supposed to be before you can do anything with it. Kinda awkward, and against the spirit of the language. Declaring multiple returns of different types doesn't seem to help much, either, since you can't declare 2 variables of different types on the same line, so you have to declare them both somewhere else, making it about as awkward as using out params. The best solution I can think of that fits with the spirit of the language is to use anonymous types. You can already do: var something = new { Foo = a, Bar = b }; something.Foo.DoStuff(); something.Bar.DoStuff(); In that case, the compiler creates a class for "something" for you invisibly, based on the properties you assigned. What's neat about that is that it maintains strong typing of everything, since it figured out the types from the declaration, so you can still do things with the Foo and Bar properties, and it knows what types they are and enforces all of the standard compile-time type checking. The downside is that you can't return these anonymous types from a method, as the method return type must normally be statically declared. You could return dynamic, but then you lose all of that static type checking, and are back to a slightly cleaner version of returning object[]. I suppose the language authors figured that it's too complex to return anonymous types from methods, as far as figuring out at compile-time what you're actually calling and what it would return. And now that I think I've successfully argued myself out of what I originally wanted to do with a ridiculous number of words, I'll just give up.