Re: Forcing an application to load assemblies from a specific path
Fernando Tubio <[email protected]> Tue, 26 May 2009 12:42:29 -0300
| Newsgroups | gmane.comp.windows.devel.dotnet.advanced |
|---|---|
| Message-ID | <039d01c9de18$ba4debe0$65043c0a@glasgow> |
"If the framework designers thought like you, "... Come on. You are being extremely unfair. I've already said that as a developer I agreed with you. Let me quote this line from my original message again. ..."Remember that this is not my application so I can't change the fact that it calls the GetMethod overload that takes a single string parameter with the method's name."... I never said adding overloads was a bad thing. My only point was that it broke applications and that I was disappointed that this wasn't handled better with side by side versioning. Remember that for an end user - who doesn't know what an overload is - the *only* option is to upgrade the application. That is my only point. - Fernando ----- Original Message ----- From: "Peter Ritchie" <[email protected]> To: <[email protected]> Sent: Tuesday, May 26, 2009 12:12 PM Subject: Re: [ADVANCED-DOTNET] Forcing an application to load assemblies from a specific path Programming "by coincidence" [1] should not put the onus on the framework to ensure all poorly written code works in a new framework. If the framework designers thought like you, their only option would be to never add overloads; they'd have to always add only new method names. This would make for an entirely unusable framework over time. By the same logic, they wouldn't be able to add any methods with new names because someone my be relying on the null return from GetMethod, or relying on a specific array length from GetMethods. That doesn't help the end-user; but realistically, poorly written code never does. The application developers have to accept the onus of writing good code for their users; something the framework designers have no control over. If anything, the framework designers should deprecate GetMethod(string). [1] http://www.pragprog.com/the-pragmatic-programmer/extracts/coincidence =================================== View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives =================================== View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives