• bvs23bkv33 (unregistered)

    who wants the d?

  • Tinkle (unregistered)

    I guess Entity Framework was not around in 2006

  • (nodebb)

    Bridge building analogy: build 8 lanes of traffic, one for each major make, like Chevy, Toyota, etc. No difference between lanes, a Chevy can easily drive in the Toyota lane, in fact, any car can drive in any of these lanes. Before entering the bridge, the engine is mildly disassembled and reassembled.

  • Sally Flynn (unregistered) in reply to Tinkle

    We had to wait until 2008 for EF to appear.

    Still, even in 2006, I'm sure there was a way to convert an object to a DataTable without diving head-first into reflection… Or maybe that's just wishful thinking.

  • Webdev (unregistered) in reply to Mr. TA

    Even trolls need to make a living, right?

  • TruePony (unregistered)

    $5 says the dev first wrote a ToDataTable method, tried to write a list of different types in the generics like <POSInvoiceRegionD, POSInvoiceRegionK>, which didn’t work the way the dev expected, so the code we see here is their “clever” hack around the “problem”.

  • David Mårtensson (unregistered) in reply to Sally Flynn

    Just using Generics, no, I do not see any way to know which properties to use without reflection.

    EF builds a model in advance, either through code first or by building it from the database to avoid reflection calls during runtime.

    But yes the example in the article is wrong any how you turn it.

  • Truism (unregistered)

    He really should reflect on his mistakes.

  • sizer99 (google)

    Since the first thing every method does is | Type classType = typeof(POSInvoiceRegionG); and then it never does anything else with the specific class, you could easily refactor this to take the Type as a parameter, solved. And now the method is truly generic without even needing any <T>. Whether or not you should do the GetProperties thing is another matter, but: | public static DataTable ClassToDatatable(Type type, string tableName) Since he had access to type foo=typeof(foobar) back then, this should work too.

  • Jaime (unregistered) in reply to Sally Flynn

    In 2006, you could still do design-time code generation. Tools like CodeSmith existed and they could inspect the database schema and build appropriate code. Visual Studio had TableAdapters back then. They weren't great, but they were a lot better than the mess in the article.

    At the end of the day, I don't see a whole lot of value in creating a DataTable that has a dynamic schema when that schema is built via reflection from your own classes. That seems to be an invitation to late-binding and runtime errors.

  • jeepwran (unregistered) in reply to Jaime

    Huh, now I'm feeling old. Did code-gen myself waaaay back in late 90's and VB6.

  • (nodebb)

    Today I learned that Rust took "putting type bounds in where clauses instead of within <>" from C#.

  • K (unregistered)

    I just wish Fortran had proper generics too... While it is a suitable choice for the domain of implementing performance critical mathematics, being able to implement generic data structures would REALLY help with the IO part.

  • Sole Purpose of VIsit (unregistered) in reply to jimbo1qaz 0

    In terms of readability, I'd say it beats covariance and contravariance in Scala. (YMMV.) I'm trying to like the more verbose "constraints" mechanism in C++, but ... no, I'm not keen on that, either. And, while Java does indeed enclose type bounds within angle brackets, it still needs the keywords "extends" and "implements," which just replaces a "where" clause with a different prepositional.

    Maybe it's syntactically preferable to position the type and the bound as locally as possible to each other, but that's really just a matter of taste.

    What is a little annoying in C# is that you can't accurately constrain a native numeric type in generics, which is something you quite often want to do. Still, every language has its warts. (Except PHP, which is basically a warthog.)

  • A Commenter (unregistered)

    Using reflection to map to a DataTable based on object properties isn't a ridiculous thing to do. Code generation tools create a whole bunch of code that you can't maintain and often gets dissociated from the toolkit used to generate it, and things like EF are good in most but not all circumstances.

    But yeah obviously you don't need to use the generic if you're going in with reflection, and if you're trying to limit the object type to one of your domain classes, use an interface or constraining base class.

Leave a comment on “Generically Bad”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article