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

I agree the C#/C/C++ syntax is  a little abstruse for conditionals that
return values (?:).  The VB IFF(cond,true-case,false-case) is better but
does not short-circuit the false-case computation if cond is true.



A more readable, slightly more abstract but basically equivilent approach
for C#, would be:
        to have a compound statement take on a value, and a slightly
different switch mechanism;

        z=
        let [y=foo(x) ] in
        test1 : [ y ];                  //z takes on y if test1 is true.  y
is calculated here
        test2 : [ y+x ];                        //z takes on y+x  y is
calculated here
        test3: [ x ];                   //z takes on x, y is never
calculated
        default : [3 ];                 // z takes on 3, the default case; y
is never calcualted.

        return z;

I don't thinkt he C# designers are too interested in adding this type of the
feature now, but it would be a welcome replacement for the , and ?:
operators.  This is totally doable in C#  in a backwards compatible and CLR
compatible manner,
and lets the compiler work out what it needs to do, rather than the
developer worrying about when to calculate y.  In this example, y is only
evaluted when its needed.



> -----Original Message-----
> From: Doug Ransom [mailto:[email protected]]
> Sent: Tuesday, May 21, 2002 2:34 PM
> To: [email protected]
> Subject: Re: [DOTNET-ADVOCACY] [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)...
> >
>