|
MrPlankton wrote: It's been awhile since I did any c++, but I believe you would get a compile warning with Borlands old c++ compiler and then it would take it's best guess
I'd rather not see it. I treat compiler warnings as errors, but from time to time I have to work with people who do stuff like try..catch with the general exception and don't even log the exception message.  The compiler cries of course but no one pays attention. *sigh*
That proposed feature is very interesting, but I'm afraid of it. 
|
|
|
|
|
Yeah, but what method should be called if I want to ignore return value?
1. int i = functA("a"); // ok int functA(string) is called
2. string s = functA("a"); // ok string functA(string) is called
3. functA("a"); // wtf?
|
|
|
|
|
well then how about a
void functA("a");
one would assume that this default case would be anticipated by programmer, but failing that;
the syntax could be;
(cast)functA("a");
and that would work to even though there is no left param;
but compiler would flag
functA("a"); with a warning.
Would that work for you? What would you like to see?
MrPlankton
|
|
|
|
|
MrPlankton wrote: well then how about a
void functA("a");
What if there's not such method?
|
|
|
|
|
You of course would write it, to handle that case.
MrPlankton
|
|
|
|
|
MrPlankton wrote: You of course would write it, to handle that case.
I thought so.  Then it's the same as with the current lack of optional method arguments - you have to write overloads and people complain. Now you would have to write void methods...
|
|
|
|
|
Well you could cast it to the method you want even if there is no left side argument.
(int)functA("stuff");
I'm just saying having the return type as part of the signiture would be nice to have from time to time.
MrPlankton
|
|
|
|
|
MrPlankton wrote: I'm just saying having the return type as part of the signiture would be nice to have from time to time
I know, I've been there myself.
|
|
|
|
|
I'd like to see a default class property.
I wrote a thin wrapper for a web service the other day, and instead of being able to access the nested object transparently, I had to add another layer of indirection.
eg:
private WebServiceWrapper<mywebservice> service = new WebServiceWrapper<mywebservice>();<br />
<br />
service.AggregateService.Method();<br />
<br />
service.Method();<br />
</mywebservice></mywebservice>
|
|
|
|
|
I was wishing for such a thing just yesterday. Ended up using an array, but the calling code is much uglier for having to unpack it.
Actually, what would be great would be something like the destructuring assignment syntax recently added to JavaScript. Imagine being able to do this:
double w;
double h;
double d;
...
[w,h,d] = CalculateDimensions(...); 
---- You're right.
These facts that you've laid out totally contradict the wild ramblings that I pulled off the back of cornflakes packets .
|
|
|
|
|
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 .
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
