Re: [Springnet-developer] Object creation invokingprotectedconstructors?
Brought to you by:
aseovic,
markpollack
Menu
▾
▴
Re: [Springnet-developer] Object creation invokingprotectedconstructors?
|
From: Mark P. <mpo...@in...> - 2007-09-11 17:42:22
|
Hi, I can see the +'s of allowing it, i.e. if a developer *really* needs to go under the covers to get something to work, we shouldn't get in the way, and the -'s of doing it, you subvert the intention of the original designer of the class. How about we provide a top level attribute to the <objects> element that allow for one to call protected constructors and appropriate API changes to the context classes. This way, the default is not to allow it, but if you need it, the requirements is made explicitly and the contract is global. It also keeps the solutions simple, i.e. not per object functionality. An additional question, should one also allow calling of protected properties, private ctor/properties? Probably something along the lines of xor'ing of binding properties would make sense if we want to go down that path. I'd guess that in some cases, people don't like having the test .dll dependencies within the 'production' assembly that gets shiped to clients, so tests are placed in a separate assembly. Cheers, Mark From: spr...@li... [mailto:spr...@li...] On Behalf Of Trudel, Stephen Sent: Tuesday, September 11, 2007 8:19 AM To: Erich Eichinger; Bruno Baia; springnet-developer Subject: Re: [Springnet-developer] Object creation invokingprotectedconstructors? The goals of TDD can be achieved as easily when the tests are inside the assembly. _____ From: spr...@li... [mailto:spr...@li...] On Behalf Of Erich Eichinger Sent: Tuesday, September 11, 2007 8:10 AM To: Bruno Baia; springnet-developer Subject: Re: [Springnet-developer] Object creation invokingprotectedconstructors? Hi, Personally I'm also not a big fan of making everything internal. Even more, I think that writing tests for my classes *outside* the assembly is a really good way for driving the design. I *want* my tests to influence the design (that's what TDD is all about I guess). Although I think Spring should somewhat enforce what we think are best practices, the world is not always ideal and there are situations where I wished that Spring supported accessing non-public code. -Erich _____ From: spr...@li... [mailto:spr...@li...] On Behalf Of Bruno Baia Sent: Tuesday, September 11, 2007 2:02 PM To: Erich Eichinger Cc: springnet-developer Subject: Re: [Springnet-developer] Object creation invokingprotectedconstructors? Hi, To do that, Microsoft uses their new feature in .NET 2.0 : the InternalsVisibleTo attribute to specify the assembly to which all nonpublic types are to be made visible. (Take a look to System.ServiceModel.dll for an example.) I've also read somewhere MS uses reflection to testes non visible classes too. Anyway, I'm really not a fan of that InternalsVisibleToAttribute because everything becomes internal now... Bruno 2007/9/11, Erich Eichinger <E.E...@di...>: Hi Stepen, playing the "advocatus diaboli" now: How do you write tests for this class then? If your design does not allow for instantiating the class, why should Spring be allowed to? -Erich _____ From: spr...@li... [mailto:spr...@li...] On Behalf Of Trudel, Stephen Sent: Tuesday, September 11, 2007 1:40 PM To: Erich Eichinger; springnet-developer Subject: Re: [Springnet-developer] Object creation invokingprotected constructors? Related question ... does Spring.Net support object construction for objects with internal constructors? If one does not want the instantiation of an object to be allowed outside the scope of a module for purposes of conceptual integrity or otherwise then Spring.Net should support its construction in my opinion ... seem somewhat awkward when class design is influenced by a framework ... _____ From: spr...@li... [mailto:spr...@li...] On Behalf Of Erich Eichinger Sent: Sunday, September 09, 2007 6:36 AM To: springnet-developer Subject: [Springnet-developer] Object creation invoking protected constructors? Steinar on the forum asked this here: http://forum.springframework.net/showthread.php?t=3448 I'd like to revisit the design decision to not allow accessing non-public types/constructors/methods/properties and hear your opinions on this. I recently ran into this issue myself when trying to provide a DI capable wrapper for "System.Web.UI.SimpleHandlerFactory" from System.Web assembly. This type is internal and can't be instantiated using Spring which required to implement a (non-trivial) workaround. The easy way would be to remove the restriction to public types. I know of opinions out there to don't enforce any restrictions within the framework. Developers should know what they are doing and if someone wants to instantiate a non-public type, let him do it at his own risk. Other opinions? cheers, Erich ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Springnet-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springnet-developer |
