Hey Kosta, Thanks, that's a good point. I don't think reflection is a soluton there for performance wise, so I made another fix to replace Activator.CreateInstance().
Atsushi Eno Konstantin Triger wrote: > Hey Eno, > > Yep, I agree it's a corner case, that can be postponed. Yet I think it's > worth mentioning in a MonoInternalNoteAttribute, just to not forget. > > In addition, there can be a performance issue related to > Activator.CreateInstance() call, that can be solved in the same time. > > On Fri, Jun 13, 2008 at 5:32 PM, Atsushi Eno <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Hi Kosta, > > Thanks for digging it. It sounds interesting, though I'm not sure how > it is significant. INullable is in System.Data.SqlTypes namespace, > so I'd expect that it is mostly for internal use. > > The fix I made for SqlXxx type support as null value is rather > to make Sys.Data classes to not premise DBNull than picking every > possible supported types. > > Of course, changing relevant to support INullable is better than > now I think. > > Atsushi Eno > > > > Konstantin Triger wrote: > > Hello all, > > It was strange to me that MS perform a special check for SqlXXX > types, so I started looking what is common to them. I saw that > all of them derive from INullable. It looked interesting, so I > created my type that derived from INullable. When I tried to set > it as a DataColumn type, I got an exception stating that I must > have a static property or field named "Null". When I added it, I > got its value for DataColumn.DefaultValue. > > Regards, > Kosta > > > > > > -- > Regards, > Konstantin Triger > RSS: http://feeds.feedburner.com/ktriger _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list