- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
The irony is that Microsoft did something similar: instead of improving XmlDocument, they rolled out XDocument, which improved the syntax but doesn't actually deliver any new meaningful features, none that would necessitate creating a new class, anyway.
Admin
Extension methods, anyone? Urgh...
Admin
Without saying that this is particularly good code, the Gang of Four design patterns also offer the "decorator", which is basically what we see here.
Admin
I mean, this is an incorrectly implemented version of the Decorator pattern, which is where you have a decorator class which implements the same interface as the class being decorated, so you still get the benefits of polymorphism. And even if they did implement it correctly, that'd still be a poor choice of pattern for this case.
Admin
You are right, the polymorphism is missing. (C# does not use duck-typing)
Admin
How do we know that Anthony's predecessor actually typed that all out manually? Maybe he used a code generator!
Admin
@Anonymous Coward
Extension Methods ("EM") have their place. But they can be an attractive nuisance that's so attractive to undisciplined devs that they multiply like kudzu into a real nuisance.
My preferred use case for them is when working against a sealed API that has some dumb or inconvenient methods or worse yet, obvious holes in their roster of methods. Or that have really bad ways of communicating failures or calls with defective parameters.
If you make sure to put all your extension methods for that API into a well structured extension class or classes, and give all your methods a fairly future collision proof naming convention (shades of App Hungarian), you can generate a much more consistent and inter-operable API surface than they provided.
Without needing to implement and use a decorator everywhere that interferes with both your and their inheritance hierarchy. IME this approach also versions better with the underlying API. As they do fix their holes and bugs, you can deprecate your fixit method and move your code to using their improved native calls at your leisure.
Admin
@Mr. TA:
I have no insider insight on this one, but given their extreme devotion to backward compatibility I'd bet they hit a bad case of brittle base class and realized they had to start over since they couldn't morph in the desired direction without leaving way too many broken barnacles behind.
Perhaps as well this was more about "future proofing" for some planned future evolution in the API that's not yet emerged into the light of day. They're typically working on vCurrent, vNext, and vNext+1 simultaneously. With vNext+2 being sketched out.
Admin
Ahhh good old days of basic. I remember spending days typing over MSX2 machine code listings from magazines, only to find out I made some mistakes and they didn't work properly. I guess I learned to type that way? Didn't learn machine code until 10 years later.
Admin
I think what Microsoft did is different enough; they wanted to create a new API but obviously did not want to break the existing one for existing applications.
XmlDocument in particular follows some RFC standard I believe. If you work with XML/HTML in JavaScript many of the API is very similar. So for example I can do document.[c/C]reateElement in both to create an XmlElement. So it's clear to me that was the goal here.
XDocument is Microsoft making their own API and from the examples on MSDN it looks friendlier and my guess is more in-line with how they usually design APIs, rather than adhering to the same standards XmlDocument does. I haven't actually used XDocument myself (I keep forgetting it exists).
Admin
I think that's an unfair generalization. I grew up in the 80's and had access to an Apple ][E starting in 7th grade. Between those magazine articles and Apple's BASIC reference manual, I learned how to write my own programs to do lots of cool things that would have wowed my fellow computer nerds if I hadn't been the only one of those in my grade.
What I'm saying is that a lot of people learned how to program by typing those in and learning how it worked as they did so.
Admin
I would argue the syntactic sugar and the only new feature (line numbers) could've been added to the existing class without breaking it. And if underlying code is bad, it's a great reason to rewrite, using unit tests to ensure backwards compatibility. Adding some new constructor and method overloads and implementing IQueryable shouldn't have regression impacts. To this day, I always use XmlDocument (in the rare case when I need to work with XML) because I just don't understand why I need to learn a new API for no good reason. And I suspect most .NET programmers do, too.
Addendum 2021-05-18 11:00: I mean, it's not like M$ is short on $.
Admin
There are multiple benefits (determining if they are more valuable than the consequences is a different subject).... The first question to answer is if there is an intended "IS-A" relationship.... That is is logically (not just computer logically) to be able to use an XMLHelper instance everywhere that an XMLDocument could be used?
Admin
That developer must have taken to heart the recommendation to favor composition over inheritance...
Admin
I didn't mean to imply it doesn't have a learning value- I still type in sample code (in lieu of copy/paste) to help myself better understand it, when I'm learning something new.
Admin
I smell cargo cult programming.
Composition over inheritance + Law of Dementer = this abomination.
Admin
There was one magazine I used to subscribe to in the 80s that stopped printing BASIC programs at one point and instead had a small BASIC loader program you would type in once, and from then on each issue's 'game' was rows of machine code in the form of hex codes which you typed in to the loader program (the last column was a checksum to ensure you typed it correctly). The games were much better because they were machine code instead of BASIC, but the ability to learn any programming from them completely disappeared. If I recall correctly, it was "COMPUTE!" magazine focused on Commodore computers.
Admin
There was one magazine I used to subscribe to in the 80s that stopped printing BASIC programs at one point and instead had a small BASIC loader program you would type in once, and from then on each issue's 'game' was rows of machine code in the form of hex codes which you typed in to the loader program (the last column was a checksum to ensure you typed it correctly). The games were much better because they were machine code instead of BASIC, but the ability to learn any programming from them completely disappeared. If I recall correctly, it was "COMPUTE!" magazine focused on Commodore computers.
Admin
I long since gave up on what Microsoft was attempting to do with it's veracious incarnations of XML APIs, yeah, we gotta use them, but they are an unholy mess.
I'd say Remy is missing a trick here. Forget this modern bit of cargo cult stuff ... I learned programming retyping those stupid magazine printouts because they were stuffed full of typos and bugs and I had to work out how to turn the resulting mess into "something".
Admin
When I was in Year 11 (Dunno what that would be in USA speak, but here in Western Australia it meant I was 15/16) and I had my Casio CFX-9850G+, I was having fun programming games onto it from printouts from the net (this was 1998).
1 version of the Snake program I found for the calculator had high scores and lives, the lives worked but the high score didn't. A 2nd version of the Snake program I found had high scores but no lives, and the high scores worked.
So I frankensteined the 2 programs together to create a single version that supported high scores and lives where both worked :)
Admin
I once worked on a framework in Java, which had a lint test with this message: "Inheritance is banned. Use composition instead". They had their reasons and overuse of inheritance is a source of pain (suffering from that right now in Python). Yet I was pretty annoyed at that framework in places because it reduced me to either writing long overloads like this one or using dynamic casts with instanceof checks (gah) because inheritance was not an option.
Admin
"Law of Dementer"? Yeah, they must have been demented!
Admin
Writing machine code in hex... Nothing to learn from that...
sigh Kids these days. Always expecting your code to be nice and prechewed with words and sugar on top.
Back in my day we punched machine code into cards with our bare fists. And they weren't paper cards either. T'was clay. We'd punch those things day and night until our hands hurt and grew two sizes and cherry red.
And than we'd hand it over to the merge team (we used to call them "gits" because they had the easy job, that's where the name comes from) who would compile all the tablets into piles and bake them in a big industrial pottery oven we held in the basement.
You could always know when we were having merge day because the whole building would heat up something awful. And everyone was running around with our suit sleaves rolled up and faning our self with our hats.
And you know what? We liked it that way. Back than you had to be a real man to get into programming.
Admin
Typing those in and changing bits to make it better. (In my case, from ZX Computing.)
Admin
CVG (Computer and Video Games) magazine for me and there was also a much more expensive (and thicker paper) one. Don't think it was "Commodore Computing International" but might have been....
Admin
An quick and interesting way to learn a new programming language is to type in all the sample code in the exercises, but alter them in such a way to accomplish a completely different program, one that you intended to write in the first place. Although, it does smack of cut and paste programming.