Evaluating a property could potentially introduce unexpected side effects. Best practices in OOP says that a property getter should never alter state, but it happens enough in the wild that I would think it to be dangerous to blindly invoke any getters during an import.
Also, presence of a property (as opposed to a field) implies that the code in the getter will be invoked each time the property is accessed. A consumer of such a construct expects this behavior, and might even depend on it. If the auto import of properties is added, then it needs to at least be an opt-in feature. Keith Rome Senior Consultant and Architect MCPD-EAD, MCSD, MCDBA, MCTS-WPF, MCTS-TFS, MCTS-WSS Wintellect | 770.617.4016 | [email protected] www.wintellect.com -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Dino Viehland Sent: Monday, June 20, 2011 2:28 PM To: Jeff Hardy; Jimmy Schementi Cc: [email protected] Subject: Re: [Ironpython-users] How can IronPython access a public static value defined in C#? Jeff wrote: > On Mon, Jun 20, 2011 at 9:35 AM, Jimmy Schementi > <[email protected]> wrote: > > If we chose to map .NET property imports to module variables, then > > we'd have to execute the getter when imported, which would break > > this example (random numbers). We could do some magic of exposing > > the PropertyInfo itself as the variable, making an getter call look like: > > SomeStaticProperty() > > ... and a setter call look like: > > SomeStaticProperty(val) > > It's really just a convenience, right? You can still do > import Color > print Color.White > > with no issues? If so, I'm also inclined to say we don't support it, > because Python has no concept like that at the module level, OTOH, if > events are importable, why not properties? I think events were an oversight - of course we could just make the decision to relax this and bring in the value of the property at the time of import *. If it changes you lose. > > If so, they should retain their property nature; otherwise it would be > too surprising. > > I would strongly prefer they still look like fields as well (x = > SomeStaticProperty; SomeStaticProperty = y) but I don't know if that's > possible. Otherwise I'd prefer .get/.set methods to overloading (). > (Too bad descriptors only work as class members ... although we could > always change the rules) > > - Jeff > _______________________________________________ > Ironpython-users mailing list > [email protected] > http://mail.python.org/mailman/listinfo/ironpython-users _______________________________________________ Ironpython-users mailing list [email protected] http://mail.python.org/mailman/listinfo/ironpython-users _______________________________________________ Ironpython-users mailing list [email protected] http://mail.python.org/mailman/listinfo/ironpython-users
