Re: [DOTNET] Constructive criticisms of C# and .NET FW

I find the loss of the "," operator in C# annoying.

Here is why:
I may prefer to write statements like:

return test ? (y=foo(x) , more(y) && less(y)) : sqrt(x);

instead of

if(test)
{
        y=foo(x);
}
return test ? more(y) && less(y) : sqrt(x);

As the examples get a little more involved, a fair bit of logic is required
to deal with the short-circuit eval of the
conditions that use a result only in some paths.  The compiler also has less
freedom to generate good code (if we cared).


I would really like C# to have the statement
"a,b,c,d,e;" to have the value e.








> -----Original Message-----
> From: Russ McClelland [mailto:[email protected]]
> Sent: Tuesday, May 21, 2002 1:51 PM
> To: [email protected]
> Subject: Re: [DOTNET-ADVOCACY] [DOTNET] Constructive criticisms of C#
> and .NET FW
>
>
> >> > C# CONSTRUCTORS NOT INHERITED
> >>
> >> > This has to be the single most maddening aspect of C#.
> >>
>
> >class Base {
> >    public Base() {}
> >    public Base(int x) {}
> >    public Base(string s) {}
> >
> >    public void Foo(int x) {}
> >    public void Foo(string s) {}
> >}
> >class Derived : Base {
> >    public void Foo(double d) {}
> >}
> >
> >Only the uncommented lines below compile (notice that I can
> call all three
> >Foo overloads with an instance of the Derived class, but I
> can only call
> the
> >default ctor):
> >
> >static void Main(string[] args) {
> >    Derived d0 = new Derived();
> >//  Derived d1 = new Derived(4);
> >//  Derived d2 = new Derived("four");
> >    d0.Foo(4);
> >    d0.Foo("four");
> >    d0.Foo(3.999);
> >}
> >
> >So while the C# team had to implement hide-by-name semantics
> specially for
> >ctors, I still think that it makes sense to only call the
> ctors on the
> class
> >you're creating. What does it mean to create via a ctor only
> in the base
> >class? That could easily lead to inconsistency in the derived class.
>
> It should mean call the default empty constructor and then invoke a
> specific superclass ctor for the rest of the build process.
> What virtual
> ctors would allow us to do is create subclasses which did NOT have to
> implement tons of ctors just to invoke a superclass ctor.  On numerous
> occasions, I've implemented subclasses that didn't need any
> ctors at all,
> but they had to implement several base class ctors so that the classes
> could be used polymorphically.  This is a hack...
>
> The other big benefit that inherited ctors would provide is dynamic
> behavior for reflection.  Why do we need MethodInfos PropertyInfos and
> ConstructorInfo classes to do reflection.  A method is a
> method is a method
> and the tool should support that.  Smalltalk had it right 30+
> years ago...
>
> Smalltalk also supported virtual Class (static) methods and
> inherited class
> data (called class instance variables)...
>