Re: [sv-ec] RE: [sv-bc] Parameterizing functions using classes -- ballot issue 225

See below.

    Arturo

Dave Rich wrote:
> Arturo,
> 
> > -----Original Message-----
> >
> > 
> > > Dave Rich wrote:
> > >
> > > Arturo,
> > >
> > > Yes, making structs behave more like classes and classes behave more
> > > like structs is the way to go.
> > >
> > I agree that structs can benefit from some class-like features, and we
> > have
> > recently passed one such enhancement that was raised by Mentor. But I
> > don't know how classes could benefit from anything available only to
> > structs? Presumably you mean static classes, which have been reviewed
> > and rejected.
> [DR>] No, static classes, is not what I had in the front of my mind, but
> put them in front of a committee with a different set of people and see
> what happens. :)

Perhaps. But I stll contend that such an enhancement (if you consider it thus)
will require the addition of dereferencing and address-of operators  (* and &
in C) and it would make the language much more difficult for 99% of users.
There's a good reason these have been kept out of Java.

> What I had in mind was all of the assignment pattern (a.k.a aggregate
> expressions) syntax, and copy by value semantics. Shouldn't we be able
> to set all of the class properties to 0 like we can with a structure by
> 
> ClassDef P = new;
> P = '{default:0};
> 

In my opinion NO!
Maybe you are considering the new operator as just a memory allocation. The 
class constructor is what takes care of object initialization, and that's what the 
new function does. There are plenty of other things that we could add to classes 
that are still object-oriented compatible --- object cloning, object compare, etc...,
but I don't believe aggregate expressions is one of them.

> > 
> > > We're doing the language a disservice if we add a template-like feature
> > > for functions and not classes, or if we later find the way that works
> > > for functions won't work for classes.
> > >
> > I'm not sure what to make of this. Classes are already parameterized, and
> > I do see problems with the parameterized function proposals that have
> > been discussed.
> [DR>] Parameterized classes still have the same problem Brad has been
> objecting to with some of the parameterized function proposals: you
> still have to instantiate a parameterized class handle for each class
> parameterization.
> > 

One person's problem is another person's virtue. The reason why parametric
classes don't suffer from infinite-recursion problems is because their declaration 
and their use (specialization) are decoupled. The problem that Brad was trying 
to solve may ultimately require a mechanism other than parametric functions.

> > > Dave
> > >
> >
>