But...wait, what?
-
Nice one today:
'Not as strange as it looks, the property set adds the object to session MemberData = MemberDatayou know what? It really works.
Maybe that should be in the constructor?
-
Maybe that should be in the constructor?
I don't know what language that's in, but I'm wondering if relying on the side-effects of assigning a member to itself is a good idea. A compiler (assuming this is compiled code) might reasonably optimize that away. However, you have to like the comment!
-
I don't know what language that's in, but I'm wondering if relying on the side-effects of assigning a member to itself is a good idea. A compiler (assuming this is compiled code) might reasonably optimize that away. However, you have to like the comment!
I assume its C# and a property. Then its a normal method call for the compiler.
-
I assume its C# and a property. Then its a normal method call for the compiler.
comments with ' ... looks like VB or so ...
-
comments with ' ... looks like VB or so ...
-
Nice one today:
'Not as strange as it looks, the property set adds the object to session MemberData = MemberDatayou know what? It really works.
Now if that were C++ and I had also written a copy constructor for the class, I'd be able to introduce some side effects that would be truly humourous. Assign NULL to some pointers, initialize some other variables. Probably make it to Coding Horrors. :cool:
Chris Meech I am Canadian. [heard in a local bar] In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
-
comments with ' ... looks like VB or so ...
Well ok. But even if its VB.Net its still the same. On the other hand its total crap to abuse a property in this manner.
-
Well ok. But even if its VB.Net its still the same. On the other hand its total crap to abuse a property in this manner.
Robert Rohde wrote:
On the other hand its total crap to abuse a property in this manner.
Although such code should never be used outside a class, since it relies upon the class not to implement caching behavior (or else relies upon some class-specific means of overriding such behavior), setting a property to itself may be a reasonable way of forcing a refresh of a corruptible copy of a property from a stable one. For example, one might have an object which manages a USB-connected lighting controller. Setting the "Brightness" property of the object will send a command to the controller to change the brightness. If external factors might disrupt the brightness setting of the external controller, it may be desirable to periodically set the brightness to the value the computer expects. If the property-set routine simply wraps a SetHardwareBrightness method, it would probably be better to call that method than set the property to its present value. If the property-set routine does the actual work itself, however, it's probably better to use the property-set routine for the refresh than to split out a new SetHardwareBrightness method.
-
Nice one today:
'Not as strange as it looks, the property set adds the object to session MemberData = MemberDatayou know what? It really works.
MMKAY
xacc.ide
IronScheme - 1.0 RC 1 - out now!
((λ (x) `(,x ',x)) '(λ (x) `(,x ',x))) The Scheme Programming Language – Fourth Edition -
Nice one today:
'Not as strange as it looks, the property set adds the object to session MemberData = MemberDatayou know what? It really works.
I try to remember to do a Find All Usages in Resharper (now in VS2010) to make sure that code inside the class doesn't use the property, only the backing field. Keeps me from writing code like that. It goes without saying that any code outside the class shouldn't even have any idea what side-effects might be happening in a public setter.
Before .NET 4.0, object Universe = NULL;