Please Microsoft Give us GENERICS as soon as you can!!!
Griffo
backwards in productivity.
Jonathan Allen
--
Jonathan Allen
"Griffo" <dearpo...@hotmail.com> wrote in message
news:#sNfsNccAHA.1436@tkmsftngp03...
Eric Gunnerson (MSFT)
They won't be in this release, however.
"Griffo" <dearpo...@hotmail.com> wrote in message
news:#sNfsNccAHA.1436@tkmsftngp03...
Alex Filippoff
"Griffo" <dearpo...@hotmail.com> wrote in message
news:#sNfsNccAHA.1436@tkmsftngp03...
Eric Gunnerson (MSFT)
can't do without them?
"Alex Filippoff" <a...@xjtek.com> wrote in message
news:O8icRXzdAHA.2184@tkmsftngp05...
Ken Alverson
news:##go#m2dAHA.924@tkmsftngp05...
> Can you expand a bit on exactly what things you would do with generics
and
> can't do without them?
Functors and therefore generic algorithms.
like
transform(inIterator,outIterator,myTransformFunctor)
or
remove_if(iterator,unaryPredicate)
Ken
Alex Filippoff
"Eric Gunnerson (MSFT)" <eri...@no.spam.microsoft.com> wrote in message
news:##go#m2dAHA.924@tkmsftngp05...
Griffo
Now onto your question:
> Can you expand a bit on exactly what things you would do with generics
and
> can't do without them?
Using C++ templates in ATL I was able to write code that was type safe and
that could eliminate a lot of grunt work.
Now, I have to go in and hand type in my code to return a Employee, a
Dependent and yada yada, somebody has to typecast, therefore, I do it in my
classes so the consumers of my classes wont have to deal with object and
therefore typecast. Somehow, IEnumerable and foreach allows us to avoid
this typecasting?
public object Current();
I'm not sure how this works but I don't have to typecase when I use foreach.
Eric, the real answer to your question is "come on", surely you can't be
serious, look at ATL and STL and then tell me that C# doesn't need a
template mechanism? This reminds me of Microsoft telling us that
Aggregation in COM is better than inheritance (jab). I realize that the
compiler must be immensely easier to write without templates, no expansions,
second pass ect.
For now I've been using Interfaces to factor out some of the cases where a
template would have been better, but Interfaces are a work around and effect
the structure of the code in an otherwise negative mannor.
- Griffo
Artur Biesiadowski
??? Why you cannot do them without generics/templates ? Very simple
example of remove_if implementation (using java syntax, because I'm not
yet C# proficient).
interface UnaryPredicate
{
boolean check(Object obj);
}
void remove_if(Iterator it, UnaryPredicate up)
{
while (it.hasNext())
{
if ( up.check(it.next()) )
it.remove();
}
}
And now if you want to call this stuff, you have to perform a cast only
in single place - in given predicate implementation
class MyPredicate implements UnaryPredicate
{
public boolean check(Object obj);
{
SomeType ref = (SomeType)obj; // you can save this single line
// perform checks on ref
// and return true or false
}
}
I hardly see this being impossible without generics.... I just have
shown you how to do this.
I agree that generics are very nice feature, but they are useful for
safety of code at compile time - they do not make anything possible
which was not possible without them.
Artur
Ken Alverson
news:3A57BBD3...@pg.gda.pl...
>
> I hardly see this being impossible without generics.... I just have
> shown you how to do this.
>
> I agree that generics are very nice feature, but they are useful for
> safety of code at compile time - they do not make anything possible
> which was not possible without them.
True, I didn't mean to imply that doing so was impossible (anything's
possible, it's turing complete), but it's certainly less than perfect. Like
you said, there's no compile time safety, a BIG downer in my opinion.
Example - overloads. Say I want to write
transform(inIterator1,inIterator2,outIterator,Addition)
I want Addition to work no matter if the input iterators are ints, doubles,
chars, decimals, times, strings, whatever. I'd like to be able to implement
acc = accumulate(iterator,initialValue)
and have it work with reasonable default behavior, at least on the common
classes. You could add an IAddable interface, but (a) this requires source
access to every object you want to store, including things like int, and (b)
if nothing else, the vtables would become immense if every object had
IAddable, IMultipliable, IDividable, etc.
Also, any solution I've found so far (for CSharp or Java) is inefficient,
either in run time or developer time, or both. I'm working on a partial
solution that relies on reflection, however I'm not sure how well it will
perform. We'll see.
Ken
Artur Biesiadowski
> You could add an IAddable interface, but (a) this requires source
> access to every object you want to store, including things like int, and (b)
> if nothing else, the vtables would become immense if every object had
> IAddable, IMultipliable, IDividable, etc.
So you prefer to rely on classes having some method defined, just by
using correct string ? So for example, instead of using java Comparable
interface, you would like to be dependent on classes implementing method
compareTo(Object obj) directly ? This is one of the things I hate most
in templates compared to 'normal' generics (like eiffel ones for
example).
Correct way to solve this is IMHO something like way used in java
collection framework - for example TreeSet requires object to either
implement Comparable OR that you provide Comparator (method pointer in
other languages). No need to bloat vtables. Of course adding generics to
avoid some casts would be nice, but idea stays the same - use
inheritance (constrained generics), not just string representation of
method name.
And as far as bloat is concerned - it is templates which lead to real
code bloat, because they require separate version for each type. You can
use them for constrained genericity as well, but almost nobody does that
- mostly for 'performance' reasons (they will work faster for concrete
subclasses) and they save few cycles for dynamic method lookup, losing a
lot of code cache locality at same time due to a larger code.
Anyway, I really think that you WON'T see templates in C#. Generics is a
way to go. This could mean no direct primitive type as template
parameters (only boxed versions), but at same time you will go away with
only single version of each container in code.
Artur
Ken Alverson
> So you prefer to rely on classes having some method defined, just by
> using correct string ? So for example, instead of using java Comparable
> interface, you would like to be dependent on classes implementing method
> compareTo(Object obj) directly ? This is one of the things I hate most
> in templates compared to 'normal' generics (like eiffel ones for
> example).
That's not what I said. I'd like to be able to have a function
int subtract(int a,int b)
and then be able to call
transform(inIntIterator1,inIntIterator2,outIntIterator,subtract)
and have it work, even in the face of multiple overloaded subtract methods.
No reliance on method names being present. No casting, no redundant code.
No change neccesary to the algorithm, no change the the type stored, no
change to the collection. I also envision functor type classes, something
like:
class subtract : basic_binary_functor {
int operate(int a, int b);
double operate(double a, double b);
//etc
}
This doesn't need to occur in a preprocessing-like system similar to macros
or templates, but it *does* need to happen at compile time and statically.
> And as far as bloat is concerned - it is templates which lead to real
> code bloat, because they require separate version for each type. You can
> use them for constrained genericity as well, but almost nobody does that
> - mostly for 'performance' reasons (they will work faster for concrete
> subclasses) and they save few cycles for dynamic method lookup, losing a
> lot of code cache locality at same time due to a larger code.
I don't believe that templates imply code bloat, although they can. I also
don't believe that the amount of code bloat are as significant as some would
imply. That said, I didn't say I wanted tempaltes. I want generics, and I
don't particularly care how.
Ken
Peter Torr (MS)
> Eric, the real answer to your question is "come on", surely you can't be
> serious
Hi there,
Somewhere (search on www.deja.com if you care ;-) ) I wrote a longer post
about why we do this -- ask you "why do you want that feature".
There are usually "obvious" reasons for wanting this (eg, type-safe
collections in the case of generics) but sometimes people have really funky
ideas that might be best solved with another mechanism. So, we ask "why do
you want to do that", and maybe the answer to your problem isn't generics,
it's something else, which may or may not already be in the product, or
planned for a future release.
Peter
--
Peter Torr - pt...@microsoft.com
JScript .NET Program Manager
Eric Gunnerson (MSFT)
collections with a single typed object, and presumably you'll test all those
paths at least once, so I don't think it's a major issue.
Generics would give you earlier type checking - which would be very good -
but not usually better type checking.
"Laurent Rodriguez" <lrod...@webmails.com> wrote in message
news:k2ke5ts85p78me378...@4ax.com...
>
> >> Can you expand a bit on exactly what things you would do with
generics and
> >> can't do without them?
>
> They make code more robust ?
>
> For example, when working with collections, type errors are caught
> at compile time and not at run time.
>
> --Laurent
>
Eric Gunnerson (MSFT)
"Alex Filippoff" <a...@xjtek.com> wrote in message
news:Ozd7GB#dAHA.1940@tkmsftngp05...
Eric Gunnerson (MSFT)
> Eric, Love your book, it's been a big help.
>
> Now onto your question:
>
> > Can you expand a bit on exactly what things you would do with generics
> and
> > can't do without them?
>
> Using C++ templates in ATL I was able to write code that was type safe and
> that could eliminate a lot of grunt work.
>
> Now, I have to go in and hand type in my code to return a Employee, a
> Dependent and yada yada, somebody has to typecast, therefore, I do it in
my
> classes so the consumers of my classes wont have to deal with object and
> therefore typecast. Somehow, IEnumerable and foreach allows us to avoid
> this typecasting?
>
> public object Current();
>
> I'm not sure how this works but I don't have to typecase when I use
foreach.
foreach has an "implicit explicit" cast; you have to state the type that
you're going to explicitly, and the compiler therefore assumes you know what
you're doing...
> Eric, the real answer to your question is "come on", surely you can't be
> serious, look at ATL and STL and then tell me that C# doesn't need a
> template mechanism? This reminds me of Microsoft telling us that
> Aggregation in COM is better than inheritance (jab). I realize that the
> compiler must be immensely easier to write without templates, no
expansions,
> second pass ect.
>
> For now I've been using Interfaces to factor out some of the cases where a
> template would have been better, but Interfaces are a work around and
effect
> the structure of the code in an otherwise negative mannor.
As I've stated in the past, we're very interested in adding generics to C#
and to the CLR. I asked what people were doing with them to:
1) Make sure that I understood what scenarios people are using, to make sure
we cover them when we do generics.
2) See if people are using reasonable workarounds for the lack of generics
in V1.
Even when generics *are* available, it's not clear whether exposing generic
types will be part of CLS, nor is it clear how generic types will interop
with languages that don't have an explicit generic mechanism. In other
words, I can't say whether using generics or interfaces (as you are now)
would be the right design choice.
While it is a resource issue, it's not a difficulty issue. We considered
having a C#-only generic implementation (probably something along the lines
of templates), but we decided it was a "bad thing" (TM). Generics belong in
the runtime, not in one language.
Eric Gunnerson (MSFT)
Thanks for the information.
I think you'll find that reflection probably isn't going to be very good
from a perf standpoint; getting metadata is fairly costly.
"Ken Alverson" <K...@Alverson.com> wrote in message
news:eqiQUBQeAHA.1276@tkmsftngp05...
Ken Alverson
> Ken,
>
> Thanks for the information.
>
> I think you'll find that reflection probably isn't going to be very good
> from a perf standpoint; getting metadata is fairly costly.
*nod* - I'm hoping that in the case of something like transform I can look
up the metadata once through reflection, and then apply hte reflected method
many times without the same lookup penalty.
Ken
Eric Gunnerson (MSFT)
"Ken Alverson" <K...@Alverson.com> wrote in message
If you have an interface-based solution, this should work. If you need to
dispatch through reflection, I think you'll find the overhead is pretty
high.
Ken Alverson
> > *nod* - I'm hoping that in the case of something like transform I can
look
> > up the metadata once through reflection, and then apply hte reflected
> > method many times without the same lookup penalty.
>
> If you have an interface-based solution, this should work. If you need to
> dispatch through reflection, I think you'll find the overhead is pretty
> high.
If I understand what you're saying correctly, even after I have a
MethodInfo, Invoke will be a slow operation. How much overhead are we
talking about? A few percent more than a virtual method? Double? An order
of magnitude? More?
I had considered this and one of my potential solutions is to emit a sort of
runtime templated method, to eliminate the reflected dispatch...of course I
have a number of issues to work out before I reach that point.
Side question - does Type.GetMethod do any conversions on the parameters?
IE, if I ask it to find a method that takes a parameter of DerivedType, and
no such method exists, but there is one that takes BaseType, will it return
that, or does it only give explicit matches?
Ken
Artur Biesiadowski
> If I understand what you're saying correctly, even after I have a
> MethodInfo, Invoke will be a slow operation. How much overhead are we
> talking about? A few percent more than a virtual method? Double? An order
> of magnitude? More?
Order of magnitude I suppose. 10-20 times as costly ?
Artur
Eric Gunnerson (MSFT)
"Ken Alverson" <K...@Alverson.com> wrote in message
news:upLg$#peAHA.1076@tkmsftngp04...
> "Eric Gunnerson (MSFT)" <eri...@no.spam.microsoft.com> wrote in message
> news:OB2oBAmeAHA.1704@tkmsftngp02...
> > > *nod* - I'm hoping that in the case of something like transform I can
> look
> > > up the metadata once through reflection, and then apply hte reflected
> > > method many times without the same lookup penalty.
> >
> > If you have an interface-based solution, this should work. If you need
to
> > dispatch through reflection, I think you'll find the overhead is pretty
> > high.
>
> If I understand what you're saying correctly, even after I have a
> MethodInfo, Invoke will be a slow operation. How much overhead are we
> talking about? A few percent more than a virtual method? Double? An
order
> of magnitude? More?
I have some code (which you're welcome to if you want) that does both
MethodInfo.Invoke() and calling through an interface. The code evaluates
polynomials.
Using MethodInfo.Invoke() is 10x slower in the big case (polynomial
evaluation is fairly long), and 70x slower in the small case.
> I had considered this and one of my potential solutions is to emit a sort
of
> runtime templated method, to eliminate the reflected dispatch...of course
I
> have a number of issues to work out before I reach that point.
That seems like a reasonable way to go, as long as you can call it in an
early-bound manner.
> Side question - does Type.GetMethod do any conversions on the parameters?
> IE, if I ask it to find a method that takes a parameter of DerivedType,
and
> no such method exists, but there is one that takes BaseType, will it
return
> that, or does it only give explicit matches?
That's one that I don't know.
Peter Torr (MS)
> Side question - does Type.GetMethod do any conversions on the parameters?
> IE, if I ask it to find a method that takes a parameter of DerivedType,
and
> no such method exists, but there is one that takes BaseType, will it
return
> that, or does it only give explicit matches?
Hi,
I just spoke to one of our JScript developers (we use this all the time).
You need to use Type.GetMethod and pass in a custom Binder object. The
GetMethod function will then call back on the Binder to ask which overload
to choose.
Unfortunately, there is no documentation for this stuff in the Beta
release...
Ken Alverson
news:uqz6EBzeAHA.1296@tkmsftngp04...
> I just spoke to one of our JScript developers (we use this all the time).
> You need to use Type.GetMethod and pass in a custom Binder object. The
> GetMethod function will then call back on the Binder to ask which overload
> to choose.
Thanks! I can see more or less how things fit together from the limited
docs. Another question then:
Any hints as to the behavior of the DefaultBinder?
Ken
Lutz Roeder
its extremly useful for stuff like:
class Foo<T>
{
void Add(T obj);
void Remove(T obj);
}
right now all this stuff needs to be implemented by
hand ... all these tons of hand-wrapped collection classes
even within the framework ...
now think about someone that has to maintain 50 such classes ...
Griffo
syntax with the built in type-cast.
Microsofts argument that we don't really need generics reminds me of the
aggregation in COM is better than inheritance argument, ludicrous but they
keep repeating it.
"Lutz Roeder" <lut...@hotmail.com> wrote in message
news:#6sJk5uhAHA.1308@tkmsftngp02...
Eric Gunnerson (MSFT)
generics.
We've said many times that you *can't have* generics in V1, but this has
nothing to do with whether you need it; it's a resource issue. Try as we
might, there was no way to get it into V1, as generics is an issue that
effect the runtime and the languages at a pretty low-level (read that as
"big destabilizing change")
I have said that not having generics isn't that bad in many cases. If you're
dealing with reference types, the difference between an ArrayList of object
and an ArrayList of MyObject is usually pretty minor (you have an extra
cast, and you get runtime rather than compile-time type checking).
With value types, the difference is bigger, since you pay the perf penalty
of boxing and unboxing.
Currently, generics in the CLR and C# can be thought of as a research
project that we're working on.
"Griffo" <dearpo...@hotmail.com> wrote in message
news:uXAYattiAHA.1580@tkmsftngp02...
Eric Gunnerson (MSFT)
>
> "Eric Gunnerson)" <eri...@no.spam.microsoft.com> wrote:
>
> [...]
> >> I have said that not having generics isn't that bad in many cases. If
you're
> >> dealing with reference types, the difference between an ArrayList of
object
> >> and an ArrayList of MyObject is usually pretty minor (you have an
extra
> >> cast, and you get runtime rather than compile-time type checking).
>
is that
> code reads more easily (and is thus more easily maintainable) with
ArrayList<MyObject>
> than with ArrayList.
I agree with you in *this* case, but I don't think it's a general argument
towards generic types. It's pretty common to see "write-only" code using
templates in C++.
>
> [...]
> >> Currently, generics in the CLR and C# can be thought of as a research
> >> project that we're working on.
>
> Is there any white paper or information available on that yet ?
No, we don't have anything we want to talk about yet. When we do, I think a
white paper would be in order.