+972 52-548-6969
On Syntactic Sugar and Weight
Greg Young posted about some issues that he run into with yield statements and compile time verifications in Spec#. He ends with:
Given this information are iterators something that are THAT desirable? Iterators are syntactical sugar, I can duplicate what an iterator does rather simply in code that does not use an iterator … Are they worth me giving up the possibility of removing all of my runtime checks or introducing this complexity?
My answer, yes, they are 100% desirable.
OO is syntactic sugar, there is enough object oriented C code out there to prove that, at least. But syntactic sugar matters, it matters because it allows you to reduce the complexity and move it to the compiler.
Take Rhino ETL as an example, the whole thing revolves around the idea of iterators. Making it any more complex than it has to will cause it to be infeasible.
The weight of the pattern or approach has direct correlation to its applicability. Dependency Injection doesn't work without an IoC container around, and iterators are far less useful if you don't have yield to make the pain go away.
Comments
It's interesting you say this, but don't like anonymous types. Or have I mis-characterized your opinion of anonymous types by making this connection?
Anonymous types are bad because they are locally scoped.
I would really like a quicker way to define a named typed. But this idea of anonymous types is bad because it encourages god methods.
Can you elaborate on the god method thing? Also, you can cheat with anonymous types, and after reflecting on this code, it might not be that bad: http://luke.breuer.com/time/item/C_30_Anonymous_Cheating/264.aspx
God methods are methods that are very very long.
Taking more responsibilities than they should.
It is an anti pattern.
I am not exactly fond of cheating.
Yes, it is a nice hack, but that is not somethign that recommends it to me.
It is interesting that you mention this. Aren't anonymous types just slightly stronger than dynamic languages, in the sense that, if you use my cheating method, the "receiving" method has to explicitly specify what it expects to get (CastExact) or the minimum requirements (CastPartial)? I could even add a CastOrDefault, which would just set properties to default(T) if they aren't found in the passed object.
The more I think about it, the more it seems we need to go this cheating route to see how it is used, then, possibly, suggest a syntax for this to Microsoft. What do you think?
Comment preview