6

I know the title is Very wide - spanning over a lot !

And I hope that this question might evolve to a bigger "info wiki thingy" on the subjects.

What I have learned - so far:

  • When using Generics - understand the concepts (covariance and contravariance).
  • Do NOT "mis-use" the concept of generics combined with inheritance. I did and it could make you head directly into covariance problems! Make sure you "break off" the generic at the correct point in you inheritance - if you are combining the two.

(please correct me - if you think i'm wrong, missing or have misunderstood anything).

My problem was:

But by now I've spend countless hours, trying to figure out, how to solve this "big puzzle" I have on my desk. And I've gotten some good answers from several of you SO users already - but now its time to get something working in a bigger scale.

I ventured into Generics with this one: Generics and Polymorphism working together

And now I'm kinda stuck on this one: Situations where Generics won't work

Why I end up with covariance problems - is because of my class procedure in my hierarchy.

So I'm wondering if Interfaces is my next bold move in this "saga". How do one "step over" a covariance problem. One thing is to find out that you actually have this problem - another thing is "how to work around it".

So IF any of you good people "out there" has any opinions on this - I'm all ears. Basically : Tell me to go for Interfaces (I have never done one from scratch myself). Or .. throw me a bone in the direction you would suggest.

My current source pool is as stated in the second link - from the top.

Here is a small snippet from my earlier post that shows my covariance problem. David kindly explained - Why I ran into the bush.. But now I need info on - How to run around it.

var    
  aList : TBaseList<TBaseObject>;  // used as a list parameter for methods
  aPersonList : TPersonList<TPerson>;
  aCustomerList : TCustomerList<TCustomer>;
begin
  aPersonList := TPersonList<TPerson>.Create;
  aCustomerList := TCustomerList<TCustomer>.Create;

  aList := aCustomerList;  <-- this FAILS !!  types not equal ..

end;

Regards

Community
  • 1
  • 1
Bimmer_R
  • 588
  • 9
  • 18
  • 1
    It would help if we actually knew what your actual problem is. In my experience, covariance is seldom a problem, if the design is not too complex. IOW, tell us the real problem, so we have something concrete to solve. – Rudy Velthuis Feb 08 '12 at 13:18
  • @RudyVelthuis Well... as you mention - it is very complex and would require a lot of rewrite from former [post](http://stackoverflow.com/q/9140485/696574). But basically its the same problem - only the question has changed. Since I now know what I have done wrong - I merely hope that someone can point me in the direction of a solution. If it's still unclear - let me know and I'll try and explain as good as I can. – Bimmer_R Feb 08 '12 at 13:29
  • How to work around the problem depends on what the problem *is*. Once you assign a value to `aList`, what did you expect to *do* with that variable? (Also, why are TPersonList and TCustomerList generic? What *else* can you have a TPersonList of?) – Rob Kennedy Feb 08 '12 at 14:22
  • In my first [post](http://stackoverflow.com/a/7872779/696574) I posed a solution where I with very few lines of code in my TBaseList.Marshal method could marshal/serialize any List in my OOP hierarchy. Generics is again used for unmarshal when going back. All I have to specify for each subclass is custom converters and reverters. It is not as much what I can have a TPersonList of - as the fact that I have like 90 subclasses of TBaseList. – Bimmer_R Feb 08 '12 at 14:50
  • FWIW, generics are a form of polymorphism. There are more kinds of polymorphism than only inheritance polymorphism. Usually, you only use one of those, and not both at the same time, although you can. – Rudy Velthuis Feb 08 '12 at 17:05

2 Answers2

5

You can't do what you want to do, but that is not how you use generics anyway. As Rob Kennedy said, it makes no sense to have a TCustomerList<TCustomer> and a TPersonList<TPerson>. The beauty of generics is that you can use the same list for different element types. That means that list and element type must not have any dependencies.

You can do something like:

procedure TSomething.ProcessList<T: TBaseObject>(const aList: TBaseList<T>);
begin
  // process the list using code that is independent of the actual type of T.
end;

...

var
  aCustomerList: TBaseList<TCustomer>;
  aPersonList: TBaseList<TPerson>;
begin
  ProcessList(aCustomerList);
  ProcessList(aPersonList);

Perhaps you may have to specify T (some early versions of generics did not handle type inference -- i.e. that it inferes the type of T from the type of the parameter -- very well), i.e.

  ProcessList<TCustomer>(aCustomerList);
  ProcessList<TPerson>(aPersonList);

But that, or something similar, is what you should do. Anything else doesn't make sense, IMO. There is no need to have a variable that could hold any of these lists, like your aList. And if you really need one, you can only use TObject, but that doesn't allow you to use the list in any useful way. And it is not very generic.

Interfaces won't help you at all with this problem. You can give classes certain capabilities, i.e. also the elements of the lists, through interfaces (another kind of polymorphism). But that won't handle covariance.

Rudy Velthuis
  • 28,387
  • 5
  • 46
  • 94
  • +1 Type inference means that you should be able to write it as `ProcessList(aCustomerList)` and `ProcessList(aPersonList)`. – David Heffernan Feb 08 '12 at 16:50
  • @David: I know, but type inference does not always work as expected, especially not in the earlier versions that supported generics. Notice that I did write ProcessList(etc.), but made the proviso that it may not be accepted that way. – Rudy Velthuis Feb 08 '12 at 17:00
  • "Perhaps you may have to specify" is a bit vague. I think that's what confused me. You may be better off coming out and saying that the concise syntax should work, but some versions of the compiler don't like it. Curiously I recently QC'd a generics bug that was the other way around. Type inference syntax worked, the alternative produced internal error. – David Heffernan Feb 08 '12 at 17:02
  • @RudyVelthuis. This looks awesome ... I was waaay off track but I really think I could get my puzzle solved with this solution. I'm going to try it in the next hour or so ... I'll be back :-) – Bimmer_R Feb 08 '12 at 19:09
  • Furthermore. The comment about interfaces - that it won't help me. What if I told you that my BaseObject has "a lot" more to it? I have several routines just for filehandling - would that be eligible as an interface. Or am I still just gazing into the sun here? – Bimmer_R Feb 08 '12 at 19:14
  • Interfaces should (IMO) be used to give any class a certain capability, like IEnumerable, IPrintable, etc. An interface should be small and only cover one aspect of a class. But interfaces do not solve covariance. TPerson and TCustomer could of course implement several interfaces. – Rudy Velthuis Feb 08 '12 at 22:52
  • @RudyVelthuis. I'm still in the process of adapting and testing my test projects. So far it looks like a solid solution. But I will get back to you soon. How do we go about summarizing all this GREAT information? I'll try and update the original post with some headlines - but who has the devine power to get the information into Delphi Help files? – Bimmer_R Feb 08 '12 at 23:30
  • About interfaces: https://forums.embarcadero.com/thread.jspa?messageID=434106&tstart=0#434106. I plan to write an article about them, but memory management comes first. – Rudy Velthuis Feb 09 '12 at 12:22
0

I would go for :

TCustomCustomerList = class(TBaseList<TBaseObject>)
end;

TCustomerList = class(TCustomCustomerList)
end;

Whether or not this is acceptable in your design is a totally different matter. If the goal you are trying to achieve is to assign a TCustomerList to a TBaseList variable, that would be the way to go.

Ken Bourassa
  • 6,363
  • 1
  • 19
  • 28
  • So you are proposing that I should break the generic chain right above the base definition ... hmmm ... I will have a crack at a test project and get back to you. Might just take a few hours before I'll be able to get back to you. – Bimmer_R Feb 08 '12 at 14:55
  • As you can see I'm currently testing ... and so far it looks as if I'll go with the advice from Rudy (basically the same as yours - but explained with more detail). – Bimmer_R Feb 09 '12 at 08:56