|
Yup. Exactly the sort of thing I was talking about. The brackets would probably be easier syntax anyway than what I recommended for the parser to figure out.
Kyosa Jamie Nordmeyer - Taekwondo Yi (2nd) Dan
Portland, Oregon, USA
|
|
|
|
|
and return [w,h,d] ?
or return {w,h,d} ?
|
|
|
|
|
PIEBALDconsult wrote: and return [w,h,d] ?
Yeah, keep it distinct from blocks, initializers, etc.
---- You're right.
These facts that you've laid out totally contradict the wild ramblings that I pulled off the back of cornflakes packets .
|
|
|
|
|
I think what your asking for can be fairly closely achieved already in C# 3.0..its just slightly more verbose:
int[] tupleFunc()
{
double w, h, d;
// ...
return new[] { w, h, d };
}
int[] tuple = tupleFunc();
|
|
|
|
|
On the flip side, native tuples in C# would be nice:
public [int,int] MinMax(IEnumerable<int> numbers)
{
int min, max;
// Compute min and max
return tuple[min,max];
}
tuple[int,int] result = MinMax(new[] { 1, 2, 3, 5, 8, 13 });
int first = result[0];
A more complex example with an "anonymous" tuple might be:
public [int,string,string,DateTime] TupleFunc()
{
return tuple[1,"String1","String2",DateTime.Now];
}
tuple result = TupleFunc();
int num = result[0];
string first = result[1];
//...
|
|
|
|
|
Jon Rista wrote: int[] tuple = tupleFunc();
But what i really want is to avoid having to unpack the array on the callee side of things.
---- You're right.
These facts that you've laid out totally contradict the wild ramblings that I pulled off the back of cornflakes packets .
|
|
|
|
|
Jamie Nordmeyer wrote: I was wondering what people thought would be good additions to the language
Oh, I forgot to address that.
1) Pseudo-virtual constructors:
I may have a class with a constructor that takes a parameter. If I derive from that class, I have to implement a constructor to call the base constructor:
public class X
{
public X ( string S ) { ... }
...
}
public class Y : X
{
public Y ( string S ) : base ( S ) {}
}
In this example, the Y constructor does nothing but call the base constructor, I'd rather not have to write it, it's busy-work that the compiler could do.
Currently, if Y doesn't have a constructor it's an error. But the compiler already knows how to add a "default constructor", why not have it add the appropriate constructor(s) in cases like these as well?
This would be most handy when defining a hierarchy of Exceptions.
2) Allow enum as a generic type constraint:
public class X<t> where T : enum { ... }</t>
There are operations one can perform on enum values which are rather difficult without allowing enum as a constraint.
|
|
|
|
|
I'd like them to include a compiler switch to treat extension methods as errors. I'd also like them to place a "feature freeze" on the language. A good programming language need not be updated every three years.
Sunny Ahuwanya
"The beauty of the desert is that it hides a well somewhere"
-- Antoine de Saint Exupéry
|
|
|
|
|
Sunny Ahuwanya wrote: A good programming language need not be updated every three years.
True... but we're talking about C#.  </cheapshot>
---- You're right.
These facts that you've laid out totally contradict the wild ramblings that I pulled off the back of cornflakes packets .
|
|
|
|
|
C# is only a prototype to find out what people want, the next language will take those concepts and be the "real" product. 
|
|
|
|
|
Oh, well then...
Treat the using directive as an error.
While you're at it, require full attribute names.
|
|
|
|
|
There are so many things wrong with extension methods that I *still* get baffled how the geniuses at M$ included that as a feature. I guess LINQ must have been a HUGE thing for every team to bend their libraries and languages to 'force' it to fit in.
I just want the option not to use it or make me use it in the "good way". This is just like the way you could set option strict in classic VB.
Luckily almost all Microsoft extension methods come with in their exclusive namespaces. So all I have to do now is not include those namespaces BUT that doesn't prevent some other genius at XYZ company to pack extension methods with regular methods in their libraries and forcing ME to write bad code.
Chip on my shoulder 
Sunny Ahuwanya
"The beauty of the desert is that it hides a well somewhere"
-- Antoine de Saint Exupéry
|
|
|
|
|
Sunny Ahuwanya wrote: There are so many things wrong with extension methods
Care to list some of them? I get that they can pollute the list of methods in a class and can cause calls to unintended methods, what else do you find wrong?
|
|
|
|
|
S. Senthil Kumar wrote: I get that they can pollute the list of methods in a class and can cause calls to unintended methods
BINGO!! Someone finally said it.
Extension methods should come with a warning label. If you search the blogosphere, you'll see developers talking about how GREAT extension methods are and how they are going to add these great "extensions" that they always wanted to the classes that came with the class library.
Imagine if I'm a newbie C# programmer and I want to perform a lot of strings to base64 encoded strings. I could create a static method and call that often, I could create a new class that has an implicit string operator that will perform the conversion or I could simply extend the string class?
Which do you think I'd choose?
Sunny Ahuwanya
"The beauty of the desert is that it hides a well somewhere"
-- Antoine de Saint Exupéry
|
|
|
|
|
Sunny Ahuwanya wrote: Which do you think I'd choose?
If you're a newbie programmer, then it doesn't matter - it'll suck. If you're just new to C#, then you'll want to play around with the tools, and it'll probably still suck.
Once you've become comfortable and competent with both the language and C# in general, then you'll make a good choice given the requirements and constraints that apply. It might well be an extension method...
---- You're right.
These facts that you've laid out totally contradict the wild ramblings that I pulled off the back of cornflakes packets .
|
|
|
|
|
Shog9 wrote: If you're a newbie programmer, then it doesn't matter - it'll suck. If you're just new to C#, then you'll want to play around with the tools, and it'll probably still suck.
Yeah, I guess it's always good to have newbies around to laugh at!
Sunny Ahuwanya
"The beauty of the desert is that it hides a well somewhere"
-- Antoine de Saint Exupéry
|
|
|
|
|
Confusion.
a) People talk about them becoming members of the class, they do no such thing, they just look like it.
b) Someone may ask "How do I do blah with X?"
Someone else may answer "Just use X.blah()" without realizing that blah is an Extension Method (perhaps internal to the company or some third-party library that the asker doesn't have).
The original asker will look in intellisense and maybe even check the documentation, but not find it.
Extension Methods are user-hostile.
|
|
|
|
|
Yeah, a bad idea implemented poorly.
What I finally decided to do was to put each Extension Method I write (I have four, none of them Earth-shattering) in its own namespace, so you only get what you ask for.
I don't use Linq either.
The only reason to use .net 3.5 is HashSet, and even that is underwhelming -- no operators! I'm guessing they only added it because they use it in Linq and didn't want to be accused of using undocumented features (again).
Sunny Ahuwanya wrote: forcing ME to write bad code.
Use them as regular static methods.
|
|
|
|
|
Extension methods are just like any other language feature...they have the ability to be misused/abused (and not just from newbies, but by anyone). I don't think that's a good reason to not include a feature or we would end up writing assembly again.
How do extension methods force you to write bad code? If you don't want to use them, don't use them. It's that simple.
Yes, there should be more guidance on how to properly use/write extension methods (which is coming) and possibly some better compiler support to enforce that. I disagree with the ability to add extension methods in the same namespace as one that's defined by Microsoft. This isn't actually polluting a namespace but rather polluting a type, but that's kind of the idea behind extension methods. BTW, other languages have similar features as well and are usually called Mix-Ins.
The thing to remember about extension methods is that they are nothing more than an alternate syntax for calling a static method on a static class. They are defined in exactly the same way (with the addition of the "this" keyword in the parameter list) and compile to the exact same IL as if you were to call it the "normal" way (i.e., as a static method on a static class and pass in the object you want to modify/act on). Calling it as an extension is a more natural syntax, but it's all syntax sugar/compiler magic.
Extension methods do not have access to the internal state or variables of the class they are extending. You also can't use an extension method with the same signature as a native method...you can declare one but there is no way to actually override the native method with your extension and it won't show up as an available method in intellisense so there is no way to call it except as a static method on a static class, in which case you no longer have the extension syntax and it's completely clear which method is being called.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
I want C# that helps me write less buggy code. This can be accomplished by integrating some Spec# features like [Pure], [Immutable], etc.
I want to be able to write yield return someEnumerable;.
I want a terse syntax for enumerables, now that they're everywhere with LINQ. private IEnumerable<Foo> SomeFunc(IEnumerable<Bar> input) { ... } is just too wordy.
modified on Wednesday, October 1, 2008 6:39 PM
|
|
|
|
|
I'd really really really like to see absolutely no changes whatsoever. Seriously.
"It's so simple to be wise. Just think of something stupid to say and then don't say it."
-Sam Levenson
|
|
|
|
|
Me too.
I think they already degraded the language in C# 3 by adding extension methods and partial methods just to sell LINQ.
Sunny Ahuwanya
"The beauty of the desert is that it hides a well somewhere"
-- Antoine de Saint Exupéry
|
|
|
|
|
Sunny Ahuwanya wrote: I think they already degraded the language in C# 3 by adding extension methods
I think of them as of an improvement and use them.
|
|
|
|
|
Pawel Krakowiak wrote: I think of them as of an improvement and use them. Smile
Can anyone explain to me how extension methods are an improvement? Besides helping to sell LINQ and encouraging programmers to write code in a non-portable, non object oriented manner, what is the point of extension methods?
Sunny Ahuwanya
"The beauty of the desert is that it hides a well somewhere"
-- Antoine de Saint Exupéry
|
|
|
|
|
Sunny Ahuwanya wrote: non-portable, non object oriented manner
Hmm, that's interesting. Is it not part of the ECMA spec? Considering there's no runtime support required for extension methods, I can't see any other portability concerns. Or maybe you are considering them non-portable because the calling code won't compile without the presence of the source code containing the extension methods?
And yeah, they are non object oriented if you consider static methods in a static class non-object oriented as well.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
