This post originated from an RSS feed registered with .NET Buzz
by Paul Vick.
Original Post: It's all a matter of taste...
Feed Title: Panopticon Central
Feed URL: /error.aspx?aspxerrorpath=/rss.aspx
Feed Description: a blog on Visual Basic, .NET and other stuff
Eric and Cyrus have been expending a non-zero amount of energy trying to rationalize why they thinkstatic importsare bad. Maybe what they should do is just come out say “Hey, we just don't like them” and then leave it at that. It seems like that would save everyone else a lot of energy arguing about what, in essence, comes down to a matter of taste.
VB has had static imports since VB 2002 and the world seems to still be turning happily on it's axis. (Actually, in addition to static imports we have standard modules, which are even worse.) We haven't been getting lots of complaints about unintelligible code being written because of it. We haven't seen lots of horribly designed APIs being produced. Which isn't to say that I don't believe that there aren't people out there abusing the feature (and shame on them!), just that by and large people seem to have taken the feature in stride and used it where appropriate. And I'm pretty confident that Java is going to see pretty much the same thing.
But, really, I don't think it's a horrible thing that C# doesn't want this feature. As much as we like to dress up language design in processes and official sounding specifications, so much of what passes for language design comes down to the particular views of the particular people designing the language on some particular day. Language is almost infinitely malleable and often times the “best” way of doing something is not particularly clear - if you ask 10 different people about some particular design point, you're likely to get somewhere between 8 - 10 different answers. Hell, if you ask the same person about some particular design point on two different days, it's possible you'll get two different answers. (It's not like every single language team at Microsoft hasn't backtracked on something at some point...) So even though rigorous intellectual analysis forms the foundation of language design, gut instinct (based on past experience, usually) can often be the decisive factor. And there might just not be any neat, logical, defensible reason why we choose to do this and not that, or implement something this way and not that way.
I think the same goes for stuff like the With statement, too. Although not everyone on the C# team might hold the same opinion on features like these, on the whole they've come to the conclusion that they don't like the features, and I think that's fair enough - they get paid to make those kinds of decisions, after all. It's not like they haven't bent over backwards to listen to community feedback and gone to great lengths to consider that feedback. It seems like in those cases a “Yup, we considered it, thought about it for a long while and ultimately decided it didn't seem like a good idea. However, we're always open to reconsidering the decision if things change.” would be sufficient....
(I will quibble with one of Cyrus's points, though: I don't believe that the Office API is the way it is because it was mangled to cater to the features of, oh, let's be honest, VB. The Office API is in many cases the way it is because it had to be designed/mangled around the past limitations of the VB language. The Excel object model is so untyped in places because it was written before OLE Automation had type libraries and could express types other than VARIANT. All the Office applications abuse optional parameters to death because VB didn't support overloading before VB 2002. And so on, and so on. The abuse of optional parameters is a particular shame because I think (and this is just personal speculation) that that is one of the reasons C# doesn't support them. I can always hope they'll see the light though...)
Previous Topic
