|There's more than one way to do things|
Re^5: What language should I learn?by Jenda (Abbot)
|on Jan 08, 2012 at 21:23 UTC||Need Help??|
OK so you'd want something like Clean-style classes. Something like
Oh wait ... in Clean this is possible because the +, -, * and / operators are defined as "overloaded", in C# there'd need to be an interface including the four operators and the types that support those operators would have to implement the interface. Then:
A bit more talkative, but as I said ... it's not a problem with the generics per se, but rather with the lack of support for them in the old libraries.
Update: Regarding the ADO.Net as a step in the wrong direction remark: I understand your sentiment regarding the ability to finetune the SQL and have access to the lower levels. The way ADO.Net took though, compared to the old ADO was IMnsHO wrong. While with the old ADO your queries returner recordsets, that could (based on the settings) be taken either as a pipe or navigated freely, with the new ADO.Net you ended up with tons of classes, tables, datasets, datarows, readers, ... It really looked like they expect you to load half of your database to memory and then god know what ... maybe run queries against the local data ... No, I did not like ADO.Net at all.
Now you can treat Entity Framework as just an ORM and let it generate all the SQL based on LINQ queries and hope for the best. Or you can tweak the code generation template and use stored procedures returning exactly what you need exactly how you need, have them propagated all the way to C# in a type safe manner and even have the properties of the returned result rows inherit attributes (even custom ones) you assigned to columns of the tables. Now I do use LINQ and I do let EF generate my SQL ... whereever I'm not yet sure what properties will I need or if the query is simple enough or changes often or I don't care about the speed. If I do care, I define a stored proc, import it into the EF mapping file, tweak the results' attributes if needed and off I go.
There are things I still hate about C#, but it kinda feels I'm going back to the functional languages I used to like at the university. Shame I don't have time to learn F# at the time. Even if I did not end up using it.