.NET to be more like JavaScript
This was an interesting read I found today: New “Orcas” Language Feature: Extension Methods. The point of the post is to discuss a new upcoming feature for .NET languages in which developers can add their own methods to objects without touching the class definition. Essentially, at any point you can add a method to any class such that all instances will have it. This is just like JavaScript, and it works for all .NET languages!
The ironic thing is that it allows you to do what I always tell people to avoid: you can’t modify objects you don’t own. While it’s possible in JavaScript, and fun to do as a hobby (most of my hobby scripts modify some object or another), it’s not a good idea to do in production code. There’s already too much stuff going on in a developer’s head to make them figure out whether a method is native or not. I know they’re trying to make .NET as extensible as possible, but whatever happened to creating a subclass or using the behavior pattern? :: sigh ::
Disclaimer: Any viewpoints and opinions expressed in this article are those of Nicholas C. Zakas and do not, in any way, reflect those of my employer, my colleagues, Wrox Publishing, O'Reilly Publishing, or anyone else. I speak only for myself, not for them.
Both comments and pings are currently closed.
8 Comments
I’ve read the post today and the thought I had was very similar to the title of your post.
But is it really such a bad practice? Doesn’t zXML do just that for example: changes Node interface to make it look similar to IE counterpart?
By the way, it seems that those minor errors in zXMLSerializer I commented on at wrox p2p forum were not fixed.
Best regards,
Alexei
Alexei on March 13th, 2007 at 4:24 pm
I do believe it’s a bad practice…now. zXml and a bunch of my other libraries do augment existing objects. To be completely fair, it’s only been recently that I’ve come to this realization that it’s not a good idea in a production environment. Most of my libraries were written while I was still learning and developing as an engineer, hence the changes to existing objects. The new stuff I’m working on eliminates all of that.
I’ll take a look at the zXMLSerializer, it could be that I just forgot to update the version available on the site. Can you send me a link to your post via email so I can doublecheck?
Nicholas C. Zakas on March 13th, 2007 at 5:04 pm
Well, there is a benefit of being on the learning curve. I can afford to use such tricks
.
without being ashamed for some time
Alexei
Alexei on March 13th, 2007 at 5:31 pm
I think it’s a nice addiction to .NET language.
I’d love if PHP have a similar thing without runkit extension.
To explain my passion to this, just look at my implementation of Aspect Oriented Programming () in PHP. I had to tokenize the entire script to enable this possibility.
If you can modify methods runtime… you can create custom pointcuts whatever you want.
Best regards,
Guilherme Blanco on March 13th, 2007 at 9:30 pm
Extending in JavaScript, especially in the way zXml extends the Node object, is fine for a few reasons:
1) JavaScript was designed for extension.
2) The environment in which we use JavaScript is the browser, and the differing browser APIs are different enough that we have to extend objects to make our lives easier.
I don’t see any reason to do this with .NET. If I want an object or class to behave like an another object or class, but have additional members, I’ll just create a subclass.
But to quote Nicholas, I’m still learning and developing, so I could be completely wrong.
Jeremy on March 13th, 2007 at 9:48 pm
Actually, I find a lot of stuff that’s in 3.0 or 3.5 or whatever is really not going to be something you’d want to do in a production system.
The whole properties stuff that Scott Guthrie blogged about this week really is just a way to make lazy programmers lazier and allows them to really make bad/hard to understand code.
Sean on March 14th, 2007 at 2:03 pm
@Jeremy – JavaScript was designed for extension, but to be fair, it was never designed for the type of enterprise usage that exists today. When JavaScript on a site was limited to 100 lines of code or less, doing whatever you wanted was fine. Once you’re doing with thousands of lines of code, you need to stop and figure out if what you’re doing scales and is maintainable. Modifying others’ objects is neither.
@Sean – I completely agree. I think Microsoft is trying too hard to make .NET "cool", and in doing so, is making it possible to write bad code. One of the things I really liked about C# was that it (mostly) forced you to write good code. Now I fear .NET may be heading down the Java highway to spaghetti land.
Nicholas C. Zakas on March 14th, 2007 at 6:47 pm
About extending native objects, the SCJP book’s view on why it’s not good to do this also applies to JavaScript:
"You’ll notice many classes in the Java core libraries are final. For example, the
String class cannot be subclassed. Imagine the havoc if you couldn’t guarantee how
a String object would work on any given system your application is running on! If
programmers were free to extend the String class, civilization—as we know it—could collapse."
José Jeria on March 25th, 2007 at 3:14 pm
Comments are automatically closed after 14 days.