Scott M. <smar (AT) nospam (DOT) nospam> wrote:
You've just said that interfaces don't bring the same level of type
safety as List<T> - so it *can't* be done. You can't do everything with
interfaces that you can do with generics. (Nor can you do everything
with generics that you can do with interfaces.)

Generics aren't trying to solve the same problem though, and generics
certainly don't replace interfaces. Either the author is confused, or
you're not understanding him properly.

Suppose I (as a client) want to only use your class with
SalariedEmployees. Someone else wants to only use it with
ContractEmployees. You (as the class provider) don't know about either
of those classes (we've created them ourselves). You only know about
IEmployee.

Now:

1) You can't provide a class which assures me at compile time I haven't
mixed and matched usages of SalariedEmployee with ContractEmployee.

2) You can only expose employees to me as IEmployee, despite the fact
that I *know* I'm only ever going to give you SalariedEmployees.

Generics fixes both of these.

Then don't just present a situation where you *don't* need them. It's
like suggesting that reference types are unnecessary because in one
particular situation you only need integers.

If you're only interested in IEmployee members, and you don't need to
allow the client to impose extra type safety (e.g. always using a
particular implementation of IEmployee) then generics has no benefit,
and just complicates matters. That's very different from saying that
you "*could* do what Generics offers with interfaces".

--
Jon Skeet - <skeet (AT) pobox (DOT) com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

Perhaps, but that was not the scenario I've proposed (see below for more).

But Generics doesn't help me here either. In your case of *knowing* that
you only ever be supplying SalariedEmployees, we'd just change my class to
accept SalariedEmployees in its constructor instead of IEmployee. And, with
a Generic:

List(of SalariedEmployees) we'd be able to pass a SalariedEmployee just as
we would with a:

New(x As SalariedEmployee) on my class.

Show me how I couldn't make a class that takes only Salaried Employees then.
I started this (with you) by asking why a parameterized constructor wouldn't
satisfy what Gernerics can when you said that I can't do a parameterized
type without Generics. I've provided an example (a parameterized
constructor). Now, you are changing the requirements to need to be able to
accept SalariedEmployees and I'm countering by saying that I'd change my
constructor parameter to accomodate that requirement. I'd have to change
the type on my Generic Type if you changed its intenal requirements as well,
so we're back to my initial point. It does not seem that your statement
that I can't create a parameterized type using Interfaces is accurate.
Please explain why I'm wrong (you haven't done that). If you simply propose
a new scenario as your proof, then I will counter with a new constructor to
accomodate your new requirement.

Scott M. <smar (AT) nospam (DOT) nospam> wrote:
No, you've missed the point. You've supplied the class to me already.
It can't be changed. Alternatively, we want to use the same code in two
places, for different types.

Yes, but in order to do that you need to know about SalariedEmployee
first, and you'd have to have one class for each type that you wanted
to treat in that way.

You could - but not in a generic way.

You can't do type parameterization without generics. What you're doing
isn't what the rest of the world calls type parameterization.

The type itself hasn't been parameterized - you've got a constructor
with a parameter, which is a very different thing.

The requirements as I understood them were to show you that generics
are necessary - that you fake them with generics.

Again, accepting a parameter isn't the same as type parameterization.

Create a class which can restrict (at compile-time of the *user* of the
class) what can be passed to either the constructor or other methods,
when you (as the class author) don't know which type I (as the user)
wish to restrict the use by.

In other words, you're going to write the class, and *then* I will
decide which type I wish to restrict the use to - just as I can create
a List<string> which will *only* store strings.

--
Jon Skeet - <skeet (AT) pobox (DOT) com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

Jon,

I do get your point and I haven't misunderstood anyting (you or the author
of the book I'm reading). You've misunderstood what I'm asking. I'm not
talking about the semantics of building a reusable class that doesn't need
to know at its creation what will be passed into it later. I get that, but
I'm talking about the mechanics of the the parameter passing and what that
parameter in the constructor does. Your getting hung up on this.

The fact is that (per my first reply to you) I *can* pass a parameter to my
type that (mechanically) acts as <T> would in a parameterized type.

But, I do think I've got what I was looking for now.

Thanks.

Scott M. <smar (AT) nospam (DOT) nospam> wrote:
So why did you ask whether it was possible to achieve everything given
by generics just using interfaces?

No, it *doesn't*. It doesn't act at all like T would in a parameterized
type. A constructor parameter doesn't parameterize the type, it acts as
a parameter for a specific instance of the type. That's a big
difference.

Well, I'm glad you think so, but it still sounds to me like you're very
confused about what type parameterization really means.

--
Jon Skeet - <skeet (AT) pobox (DOT) com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

Scott M. wrote:

Scott, I think I understand what you've misunderstood. I think you
somehow got the idea, once upon a time, that generics enable a certain
class of solutions, where such solutions are semantic in nature (e.g.
write a class that can "maintain a list of stuff", etc.). Now, you've
stumbled across interfaces, and it's dawned on you that you can use
interfaces to do the same semantic thing ("maintain a list of stuff" so
long as "stuff" implements the interface) and you're seeing a semantic
equivalence here.

The thing is, the feature that generics brings to the table, isn't this
capability to implement certain semantics (and thus being equivalent or
a subset of interfaces); it's rather that it enables such semantics *in*
*a* *statically-typed* *way* - and this is the very feature that
interfaces / polymorphism *doesn't* provide. They only work with dynamic
typing.

A parameterized type is a type constructor. By passing it type
arguments, you're creating what effectively is a *new* type, statically
checked at compile time. You *cannot* create such a new type by passing
an interface reference to a constructor.

You know the features that generics bring to the table, but you're
thinking in terms of end results, i.e. observable program actions, and
you can see that interfaces (or ever System.Object) can do the same
thing. But the trouble is, that isn't what generics are about - they
aren't about enabling new kinds of end results, to the exclusion of
other possible implementations. They're all about static typing. Plain
and simple.

-- Barry

--
http://barrkel.blogspot.com/

I understand (and have understood that) Barry. I do not misunderstand the
concepts. Perhaps I wasn't clear enough in my question. My questions have
been about the observable results, not the purpose or under the hood
benefits of generics. I am asking for academic reasons.

Scott M. wrote:

Then there's a direct logical contradiction in your position: your
questions are for the "reasons", but not the "purpose" - but the purpose
is the reason!

-- Barry

--
http://barrkel.blogspot.com/

I don't believe I ever stated what you are saying. I asked why I can't get
the same result with Interfaces that I can with Generics. I should have
been clearer that when I say "result" I meant "end result", not operational
results.


"Barry Kelly" <barry.j.kelly (AT) gmail (DOT) com> wrote

"Barry Kelly" <barry.j.kelly (AT) gmail (DOT) com> wrote

You're drawing equivalence where there is none:

His reasons (asserted to be academic) for studying generics need not be the
same as the language designers' purpose for providing generics, even if the
words "reasons" and "purpose" be synonyms.