Public Fields vs. Properties?

Oct 2, 2010 at 12:33 AM

First off, Wow. :)

Secondly, I'm seeing a lot of public fields (as opposed to properties) and I'm wondering what the thought is behind this design decision.  It wouldn't be so bad if I could put a breakpoint on the field to see when it's getting set/get. :)

Very impressed otherwise.  Caliburn has been put on a treadmill!

Oct 2, 2010 at 4:53 AM

It mostly has to do with trying to cut down on the assembly size in any way possible. You'd be surprised what you can shave off by change properties in fields and doing a few other interesting things.

Oct 4, 2010 at 6:57 PM
Edited Oct 4, 2010 at 8:54 PM

This is a great ideal to aim after.  However, let's not sacrifice the fundamentals. :)

(And FWIW I think Micro is *TOO* Micro... it could use a little more meat!)

Oct 9, 2010 at 10:38 PM

Also from my side, please use properties :) Size does not matters ;)

Oct 11, 2010 at 12:32 PM

I somehow agree with the others. Leaving part of the configuration open during the lifecycle of the application is not always an option. Typically you want to configure your environment, finalize the configuration and go on. Using public members prevents this kind of behaviour, leaving the core of the application open to modifications (that could be done by plugins/addins).

On the other hand, using properties it is possible to decorate the set method with proper code to avoid such situations (it is possible to create a Freeze method to avoid further modifications of the relevant delegates).

Of course, this does not prevent me from using CM! :)

Oct 18, 2010 at 12:19 AM
Edited Oct 18, 2010 at 2:36 AM

After reading this thread (and having posted previously about this subject), I decided to do as BladeWise (and Nereidum in the other thread) suggested and added the ability to lock static members.  I committed my code to a fork of CM here:  It was based on the latest CM build, c579c0a63feb.

Note that this was purely an academic exercise, and I have no current intentions of maintaining the changes as CM evolves.  If someone else wants to do so (or if Rob changes his mind), feel free to take it and roll.  Also, I only did the WPF project, since I do not have the SDKs for Silverlight or WP7 installed.

Another reason I did this was to determine just how much of a difference using properties vs. fields made.  Rob is correct, the properties do increase the size.  I don't consider it too much, but then again I don't speak on behalf of any devs targeting very small footprints.  The size-on-disk results are (Release build, readonly fields excluded):

  • Original CM:  70,144 bytes
  • Only static Funcs/Actions converted to properties:  74,752 bytes
  • All other static members converted:  75,264 bytes
  • Additional code to lock overriding static members:  76,800 bytes

If you want to take advantage of locking, in your subclass of Bootstrapper, call LockStaticMembers().


Link modified to point to latest changes (obviously, static members should NOT be locked by default... oops...)

Oct 18, 2010 at 2:44 AM

A hint... if you use that code, you'll probably need to do something like the following:

        public MyBootstrapper() : base()

            // Now, initialize addins/plugins

Unfortunately, Bootstrapper's constructor sets up the IoC methods after the Bootstrapper calls Configure(), so that means you can't do this during Configure().  There are probably other ways, but I'd rather make as few unnecessary changes as possible to CM.