February, 2007

Posts
  • Eric Gunnerson's Compendium

    Properties vs public fields redux...

    • 27 Comments

    My blog reader burped recently, and gave forth a post (and reply) than Rico wrote last September, but since I didn't comment on it then, I'll comment on it now. And, yes, I've written about this in the past...

    Basically, this revolves around the question of using properties, or using public fields. And I have a slightly different point to make than Rico is making, his point being that sometimes you need to break these guidelines for performance reasons (which I agree with, but which is not my point).

    But first, a bit of history...

    Back in the early days of .NET, we (and by "we", I mean "other people") were coming up with the .NET framework library coding guidelines and the CLS as a way of making sure that developers could use assemblies developed in multiple languages without severe cranial performance issues. Meetings were held, discussions ranged far and wide, and the CLS and coding guidelines came into being.

    And they were pretty good, though they only covered the public appearance of classes. You could use hungarian in the internals of a class, if you wanted to.

    We also discussed whether we would come out with a set of guidelines that talked about how things should be done inside your class. For C#, we decided not to do this, and if any of you have ever spent time talking about where braces belong or whether source code should use spaces or tabs, you understand why we decided not to do this.

    But I'm afraid that it unfortunately gave the impression that the library coding guidelines should be the drivers for all code that you write, and I think that's the wrong way to look at things. Others may differ inside MS, but they can write their own blog posts...

    On the specific subject of properties, the question can be boiled down to:

    If I have a field with no special behavior, should I write a "just in case" property (with trivial get/set), or should I expose a public field?

    The reason that the library design guidelines suggest you write a property here is that it is important that libraries be easily versioned. If you put a property in there ahead of time, you can change the property implementation without requiring users to recompile their code.

    That, in my book, is generally a "good thing".

    Or, to put it another way, I rank the ability to version easily higher than the cost of the extra clutter in the class and increased size of the assembly that comes from the property.

    But, if the clients of a class are always compiled together with a class - or at least shipped together - then there is no versioning issue to consider. In that case, I think it's a bad idea to write the "trivial property" - all you've done is complicate your code without any benefit. If the public field you write needs to be a property, then just make the change and recompile.

    I've switched over to writing this code, and I have to say that when I have to work with old code with trivial properties, it bothers me.

    (Oh, and I also made the same choice as Rico when I had to do some graphical stuff...)

    Comments?

  • Eric Gunnerson's Compendium

    More on properties vs fields

    • 6 Comments

    Some nice comments on what I wrote.

    First, a non-controversial question. Robin asked whether you would capitalize them in that case, and I think you should, as having something accessed externally that isn't properly cased will be surprising to people.

    Dani - and others - have pointed out that properties leave your options open in case the software is used in ways that make the property more useful. This is certainly true, and I think it comes down to how you value that flexibility over the tax that you're paying to have properties. I would usually rate the simplicity higher, but it does depend on what you're writing, how likely the code is to get repurposed, and how likely it is that a property would ever be needed. I find as I get older I'm valuing simplicity more.

    Finally, Kristof points out that a field can be passed as an out or ref parameter while a property cannot, which means that adding a property to code can break the client code. This is a good point. I do think, however, that I'd want my code to break in that situation - if something is a property I should do some thinking about whether it's a good idea to be passing it as an out or ref (the same reason C# doesn't write helper code to make this work by default).

    Kristof's comment reminded me one more reason to use properties - some of the BCL infrastructure works with properties but not with fields.

     

  • Eric Gunnerson's Compendium

    Taking snapshots of WPF animation

    • 2 Comments

    I've been playing around with WPF animation, and ended up wanting to take a snapshot of an animation at a specific place.

    Specifically, I have a canvas that has some pictures on it that are moving, and I want to be able to save a bitmap of what it looks like at a specific time.

    Getting the bitmap is pretty easy, using a RenderTargetBitmap and a VisualBrush.

    private BitmapSource CaptureScreen(Visual target)
    {

        Rect bounds = VisualTreeHelper.GetDescendantBounds(target);

        RenderTargetBitmap renderBitmap = new RenderTargetBitmap(800, 600, 96, 96, PixelFormats.Pbgra32);

        DrawingVisual dv = new DrawingVisual();
       
    using (DrawingContext ctx = dv.RenderOpen())
        {
            
    VisualBrush vb = new VisualBrush(target);

            ctx.DrawRectangle(vb, null, new Rect(new Point(), bounds.Size));
        }
        renderBitmap.Render(dv);

        return renderBitmap;
    }

    That gives you the state of the objects pre-animation, but what I really wanted was the state of the objects during the animation. I had some code to move the image around:

        DoubleAnimation anim = new DoubleAnimation(50, 400, TimeSpan.FromSeconds(10), FillBehavior.HoldEnd);
        AnimationClock clock = anim.CreateClock();
        m_imageLeft.ApplyAnimationClock(
    Canvas.LeftProperty, clock);

    After a bit of research, I settled on the following bit of code to set the animation to the point that I wanted:

        clock.Controller.SeekAlignedToLastTick(TimeSpan.FromSeconds(5.0), TimeSeekOrigin.BeginTime);

    Which should have worked fine, but didn't. When I looked at the properties, I noticed that the Left property was changing, but it wasn't showing up. It was almost as if the Canvas didn't know that the object property had changed and a re-layout was necessary...

        m_canvas.UpdateLayout();

    was the magic incantation to make that happen.

    (Note that I'm a novice at WPF, and there may be a better way to do this...)

  • Eric Gunnerson's Compendium

    Where is the file menu in Word?

    • 8 Comments

    In case you're as stupid as I am...

    You get to the file menu operations in the new Word by clicking on the round "jewel" in the upper left.

    I'm afraid I won't admit how long it took me to figure this out.

  • Eric Gunnerson's Compendium

    Performance Problems Survey

    • 0 Comments

    Rico (who I am currently listening to on a new episode of "Behind the Code") posted an interesting survey about performance problems. And then he posted a follow-up.

    I think that's one facet of my "Premature Generalization" sin...

  • Eric Gunnerson's Compendium

    Back on the 'sauce

    • 3 Comments

    My grandfather on my mother's side was an orchardist, growing apples and pears just outside of Yakima. Every fall we would head over the Cascades to visit them, and we always came back with lots of fruit - primarily apples and pears, along with a few cherries from my uncle - stuffed wherever there was room in the car. Under the trunk bottom. Stuffed around suitcases. Sometimes under our feet.

    In a somewhat ironic twist of fate, the grandson of an apple farmer can't eat raw apples or apple juice. Makes my stomach hurt. The cooked stuff is fine.

    Which brings us to apples. These days, there are lots of different varieties of apples in my local supermarket, but in the 1970s, you could either get red "delicious" or golden "delicious". The "delicious" brand apples were chosen (and subsequently bred) not for their flavor, but for their color and their ability to last in cold storage until the next fall, providing "fresh" apples all year round.

    Most orchardists kept part of their orchard in varieties that they would like to eat themselves, and grandfather Schwartzwalter grew Gravensteins, a great apple that doesn't keep well. They will last for a few weeks, but for longer term storage, you need to freeze them.

    Which brings us to applesauce. Cut up the apples, run them through the food mill, and put the sauce in containers and into the freezer. When you want a snack, pull out a container, wrap it in a towel, pull out a grapefruit spoon (or better, a melon baller), and go to town. I'd usually eat a cup or so at a time.

    I've made applesauce myself when I could find graventsteins, but these days I don't have the time, and I miss eating the frozen stuff. But this week I was walking through Safeway, and came across single-serving containers of Granny Smith applesauce. Not gravensteins, but a decent subsitute. Just toss them in the freezer, and you've got a nice, single serving of frozen applesauce whenever you want it.

    So I'm back on the 'sauce...

     

     

     

     

    In a somewhat ironic twist of fate, the grandson of an apple farmer can't eat apples - they make me sick to my sto

Page 1 of 1 (6 items)