Confession: My name is Lars Fosdal, and I am a writer of frameworks.
It’s just so hard not to do it!. I really dislike cut & paste code or having to rewrite the same code with just different types! Generics are really addictive, and I fear I have become a user.
remember, code like the next guy is an axe power user that will NOT hold back on finding where you live and force you to fix your framework
I wish Delphi had something like C++ lambda syntax
what they implemented made them hardly usable in practice
And I fear you might also be infected with the overgenerification syndrome. When I see people making half the class hierarchy generic just because they pass in some class as generic parameter somewhere (which would have worked just fine with passing a TClass) it drives me crazy.
Is there a cure? 😉
Lars Fosdal yep, wait for it to bite
Lars Fosdal Take the pill of degenerification and refactor code that doesn’t have to be generic because it works fine with TClass or PTypeInfo.
“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live”
I think this quote is from John Woods.
Arioch The
Anonymous methods are similar
Borja Borja syntax is uber-boilerplate making lambdas anti-concise, thus killing their value
Martin Wienold An oldie but a goodie! Hilarious!!
It’d be great if the compiler automatically refactored old code depending how is it used, per-unit. ie: “autogenerication”, or at least some hints
Martin Wienold I just hate it when I am the next programmer to my code…
Nicholas Ring Stabbing yourself? :p
Stefan Glienke Mentally, yes 🙂 I think it comes back the “WTF count” 🙂
Was it you who tried to use generics with visual inheritance? In that case, yeah… I’d say it’s borderline addiction.
Lars Fosdal Your cure is KISS, “Keep it Simple, Stupid”. Repeat to self 50 times before you create another framework when a class will suffice.
It usually starts when I get tired of writing scaffolding…
I just love the pic! Rocks.
“I really dislike cut & paste code or having to
rewrite the same code with just different types! ”
Just look into a mirror, say “dynamic typing is superior to static typing” and a weight will be lifted from your shoulders! 🙂
Delphi’s type system (along with C, Java, etc.) is rather “old school”. Type theory has advanced so far that I know functional language programmers who don’t even consider languages like Java to have “real” static typing. 🙂 Heck, F# lets you create types with units so you don’t inadvertently add kilograms and meters despite both being integers or floats!
Ceylon isn’t functional but uses union and intersection types so variables can have multiple types while still preserving static typing!
https://en.wikipedia.org/wiki/Ceylon_(programming_language)#Type_System
With Ceylon it’s trivially possible to do something I didn’t think would be possible to do in a statically typed language – create a dictionary that allows different types for the values!
All that said, dynamic typing gives you generics “for free”, which is nicest of all.
Can you have strict typing and dynamic typing?
I am sort of addicted to strict typing.
It is static vs dynamic typing (compile time or runtime) and it is strict vs weak typing (how stricly are types distinguished).
See: http://stackoverflow.com/a/2351203/587106 or for more reading https://en.wikipedia.org/wiki/Type_system
And also when some languages don’t require explicitly stating a type for a variable that does not make anything dynamic. It just means their compiler is not completely retarded and can infer the type from the assignment and then declares this variable as of this type. Any subsequent assignments to it with a wrong type will result in a compile time error!
Which is why it is my personal opinion that the need to predefine variables in Delphi is really archaic and does not lead to any better code than in languages where you can declare them inline as needed.
Stefan Glienke I would not mind inline declaration and limited scope for sure. Type inference would be good too, but I still would like the option to be explicit if needed, both scopewise and typewise.