my point was that generics do not always work even when well defined, and sometimes you have to fallback on raw types.
i look at this from the point of view of the framework developer: what is the easiest/simplest/most intuitive for most users. to me that is simply idataprovider<t>, i can look at it and immediately understand what <t> is. as you can see your proposal of <a,b> already required one explanation in this thread. so, from my point of view, you are asking me to complicate something to support your usecase, which i consider uncommon. you see where i am going with this? i cant justify it yet. i understand your usecase, but i also see ways of working around the limitation that are not too horrible, at least to me. that is why i suggested you start a vote/discussion on user list. you dont have to convince me that your way is better, you just have to convince me that the added complication is acceptable to our users. i have no problem changing my mind. -igor On Wed, Apr 23, 2008 at 10:41 PM, Jan Kriesten <[EMAIL PROTECTED]> wrote: > > hi igor, > > > > > i dont think we are cutting anything out. i am sure i can still come > > up with examples where generics do not work on component or model: > > such as a model that returns different-typed objects based on some > > condition. > > > > that's actually a quite different case than this, since here there are no > conditions to be evaluated. > > > > > in these cases you simply use the raw types and supress the > > warning. why can you not do that for your particular usecase? > > > > the point of using generics is to provide type safety and don't have to > assume types using casts. in my case it's breaking a structure i set up not > to have to cast when using generics. i'll send you a pm example how that > works for me. > > best regards, --- jan. > > >
