Cyrus likes Weak & Strong references


Then Cyrus decided he wanted to support weak references.  A weak reference is one that the GC can decide to release if there are no other references to it.  


 


For our LazyLoader, that would mean that you create the item when demand appears, and it may go away if it’s not needed, and then it’ll come back later if needed again.  At that point, you really do have a cache.


 


To do this, Cyrus first built some cool classes to handle weak and strong references.  You could think of IStrongReferenceas being the same as a regular reference in C# today.


 



interface IReference<A>


{


    A Value { set; }


 


    IOptional<A> Target { get; }


}


class StrongReference<A> : IReference<A>


{


    IOptional<A> target = None<A>.Instance;


 


    public IOptional<A> Target


    {


        get


        {


            return target;


        }


    }


 


    public A Value


    {


        set


        {


            target = new Some<A>(value);


        }


    }


}


class WeakReference<A> : IReference<A>


{


    System.WeakReference reference;


 


    public WeakReference()


    {


        Value = default(A);


    }


 


    public IOptional<A> Target


    {


        get


        {


            IOptional<A> target = (IOptional<A>)reference.Target;


            if (target == null)


            {


                return None<A>.Instance;


            }


            else


            {


                return target;


            }


        }


    }


 


    public A Value


    {


        set


        {


            reference = new WeakReference(new Some<A>(value));


        }


    }


}


 


Note that you can have a strong or weak reference to ‘null’, and that’s not the same thing has not having a reference as all.  ‘null’ is a value, and None<> is not a value.  Ahh, the power of IOptional<>.


 


One other thing Cyrus mentioned is that he might put these in a References namespace, and refer to them with FQNs:


 


          References.IReference


          References.Weak


          References.Strong


 


That reads well, but C# wasn’t really built for it, IMO.  A question of style, I guess.


 

Comments (13)

  1. WeakReference<A>:Target seems a bit inconsistent with StrongReference<A>:Target.

    In one case you’re relying on a null value to mean there is nothing, but in the other case you’re using None<A>.Instance as the default.

    Also, it seems that after you initialized a reference (with the Value property), you never can revert to the original state.

    And why use properties in this case? Only the setter or the getter are actually implemented. Is this just to spare some parenthesis?

  2. Cyrus Najmabadi says:

    Julien, an essential invariant of the Target getter is that it _never_ returns null. null is not a valid value for it. It must return either a None<> or a Some<>. Unfortunately, I can’t guarantee that with the code in it’s current form. Someone could implement IReference<>.Target to return a null value, and i should harden the LazyLoader code to take care of that.

    Note: You are correct. There is a bug in the WeakReference code. Let’s look at StrongReference<>. In that case we see the invariant holds because target is initialized with None<>.Instance, and it can only be set to an instance of Some<> (in the Value setter). So we can see that Target can never return null.

    In WeakReference<> however we can see that when you instantiate the WeakReference<> we winn instantiate the reference to a "new WeakReference(new Some<A>(null));" which would be incorrect. Instead, we want to write this:

    public WeakReference()

    {

    reference = new WeakReference(None<A>.Instance);

    }

  3. Cyrus Najmabadi says:

    Julien, you also mentioned: "Also, it seems that after you initialized a reference (with the Value property), you never can revert to the original state. "

    That’s correct, but it’s by design. Think of a referene like a C# local. say I have:

    String s;

    It starts out uninitialized (it’s not even null). Then once you initialize it that’s it, you’re done, you can never go back to being unintialized.

    In one of Jay’s recent posts he talked about why we implemented "IOptional". Why it was necessary when you needed a sentinal value to indicate something when there wasn’t a value available in your domain. This is true of references. How do you tell if something has been set to null, versus something that has never been set. I could keep around a boolean flag as well as the value, but then you see that that boolean was eliminated through the use of the Some<> and None<> types.

  4. Cyrus Najmabadi says:

    Julien, in response to your last comment: "And why use properties in this case? Only the setter or the getter are actually implemented. Is this just to spare some parenthesis? "

    The proper use of methods/properties is still vague to me and i don’t have clear rules defining how i should use them. However, in this case properties seemed more natural. If you have a reference there were two (or maybe three) things I’d like to do with it:

    a) Get it’s value

    b) Set it’s value

    c) Check if it’s value was set

    In method form that would have been written:

    A GetValue()

    void SetValue(A value)

    bool IsSet()

    Those looked a lot like properties to me. However, i decided to wrap a and c together into one call. This was essential in the WeakReference case where you might make a call to IsSet, get "true" and then fail when you called GetValue. In other words, i needed the action of IsSet/GetValue to be atomic, which is why it seemed natural to have just one call that returned the IOptional<>

  5. What about implementing IOptional and IReference as structures instead of classes?

    Structs can’t inherit from other structs, but they can implement interfaces, so it should work here.

    The idea is that in the case of IOptional, if you had coded it by hand you would just have added a boolean (bIsInitialized) next to the reference, without adding an extra indirection.

  6. Cyrus Najmabadi says:

    Julien:

    I’d like to hear more back from you on why you think struct would be more appropriate here then classes. What problem does that solve?

    Also, i initially started with an Optional<A> type that included the bool flag. However, i’m not a big fan of state. It clutters up your type and it makes your methods far more complicated than they need be. Inheritance solved this for me (much in the vein of Fowler’s "Replace Type Code With Subclasses" refactoring). Instead of needing a large method that is checking lots of state, I have two distinct methods that make sense (to me). Asking a None<> for it’s value just throws. Asking a Some<> for it’s value just returns the value. With the bool system i’d also have to add a HasValue property (thus complicating the interface). This way I can just ask it "are you something? or are you nothing?" Maybe the names should have been Something<> and Nothing<> instead of Some<> and None<> 🙂

  7. I was just thinking in terms of memory locality. Having a class is an extra level of indirection/reference.

    It’s probably wrong of me to think "optimization" without having any actual data… 😉

    I agree that using inheritance instead of using a bool is cleaner, but it feels somewhat over-engineered, for some reason 🙁

  8. Is a type check costly? Does it involve any reflection?

    Maybe IOptional could have a extra method, to avoid testing on the type. None<>.HasValue would always return false, Some<>.HasValue would always return true, so inheritance is still used.

  9. jaybaz [MS] says:

    A type check is more costly than storing state and having a bool, but not as costly as reflection.

    Anyone feeling industrious enough to runs some tests?

  10. To jay: Nope. If the implementation runs fast enough then i’m fine with it. If, however, it turns out that this is the bottleneck in some system then its something to come back and look at.

    The least expensive solution to this will most likely be written in hand tuned assembly.

    To julien: it certainly wouldn’t hurt to add a HasValue property (except for the vtable size increase (which doesn’t really bother me)). There’s a tradeoff though. We’re complicating the interface without adding any additional benefit (why add something that the language gives you for free?).

    I’ve worked on projects with the following code structure:

    class Base {

    bool IsDerived1() { … }

    bool IsDerived2() { … }

    Derived1 AsDerived1() { … }

    Derived2 AsDerived2() { … }

    }

    class Derived1 : Base { … }

    class Derived2 : Base { … }

    i.e. instead of using strong runtime typing, we built in subclassing programmatically instead of using what the language gave us.

    I’m very much against this style of programming.

    Also, i tend to not think of costs until i have to. I prefer simple conceptually clean implementations before spending on a lot of energy on what might only be a 1% gain.

    The last project i worked on had hotspots in 3 places. Fixing up those areas gave me back a 20x boost in performance. They weren’t things that had leapt out at me while coding, and the places that i thought might be a problem didn’t even show up as blips on the profiler analysis.

    Adding state and extra methods to sidestep the built in language constructs seems like like over-engineering to me 🙂

  11. I still like the use of a HasValue method, rather than the type.

    In O’Caml for example, a pattern matching would really make sense (with None and ‘a Some). But altough C# supports the type checking, it doesn’t seem natural (to me at least).

    Also, I understand your "anti-pattern" example, where the type system is kind of manually rebuilt, but I don’t think "HasValue" falls in that trap.

    How would you test for "HasValue" if you had three types: None, Little and Lots ?

    What if you had two types for "nothing" and two types for "something"?…