bcuff / autolazy Goto Github PK

Maybe consider something like this in LazyWeaver.cs:

    public bool Instrument()
    {
        **Context.Weaver.LogInfo($"Instrumenting [Lazy] to {Method.DeclaringType.FullName}.{Method.Name}.");**

this will also help in debugging in order to figure out if AutoLazy didn't instrument to some property we were expecting.

I stumbled across this while looking at what people have done with Fody and was intrigued. I haven't looked at anything but README.md, so it's possible that the weaver itself is fine. I'm not planning to spend too much more time here, so I'm sticking to just README.md and there's a nonzero chance I'm just going to disappear like a ghost after logging this.

1. I'm pretty sure all your instances of volatile are unnecessary and likely harm the common case (to a small degree). Monitor.Enter and Monitor.Exit are both full-fence, so you should already have the same guarantee at double-check time that volatile enforces (which is where it really matters), without having to pay whatever the volatile read cost is on every initial check after it's populated.
2. The getter for Settings doesn't actually set the _settings field.
3. Dictionary<TKey, TValue> throws when the key is null, so you should probably be weaving in some kind of special handling for that. Suggestion: separate TValue-typed field that says the value to use for a null key.

I have a class nested inside another class, and had a get-property with the Lazy attribute. While testing I saw AutoLazy behavior was not applied to it.

example test program:

class Program {
static void Main(string[] args) {
var outer = new OuterClass();
Debug.WriteLine(outer.GetProperty);
Debug.WriteLine(outer.GetProperty);

        var inner = new OuterClass.InnerClass();
        Debug.WriteLine(inner.GetProperty);
        Debug.WriteLine(inner.GetProperty);
    }
}

class OuterClass {
    [Lazy] public int GetProperty {
        get {
            Debug.WriteLine($"Running {nameof(OuterClass)}.{nameof(OuterClass.GetProperty)}");
            return 1;
        }
    }

    public class InnerClass {
        [Lazy] public int GetProperty {
            get {
                Debug.WriteLine($"Running {nameof(InnerClass)}.{nameof(InnerClass.GetProperty)}");
                return 2;
            }
        }
    }
}

output:
Running OuterClass.GetProperty
1
1
Running InnerClass.GetProperty
2
Running InnerClass.GetProperty
2

expected output:
Running OuterClass.GetProperty
1
1
Running InnerClass.GetProperty
2
2

This is a really cool project.

If the result of the body of the property is null, then the body of the property is called each time.

This could be fixed using a slightly different implementation:

// begin - fields added by the post-compile step
private static Lazy<Settings> _settings = new Lazy<Settings>(() => __Settings);
public static Settings Settings { get { return _settings.Value; } }
// end

// Property is made private and name changed somehow
private static Settings __Settings
{
	get
	{
		using (var fs = File.Open("settings.xml", FileMode.Open))
		{
			var serializer = new XmlSerializer(typeof(Settings));
			return (Settings)serializer.Deserialize(fs);
		}
	}
}

Fody Version 2 is out and you will need to do an update for your adding to be usable with it

Specifically:

• Update to the newest Fody.Cecil nuget
• Change the min dependency ranged for Fody to be at least 2.0

Hey,
is there any reason behind not using a ConcurrentDictionary and instead locking the method for all calls? It would be quite an improvement if you wouldn't lock the whole method for different parameters.

It would be better if you would keep a second dictionary that contains lock objects and only lock on a global lock for checking this dictionary (and lock on individual locks for unique parameters).

1>MSBUILD : error : Fody: The weaver assembly 'AutoLazy.Fody, Version=2.2.1.0, Culture=neutral, PublicKeyToken=null' references an out of date version of Mono.Cecil.dll. Expected strong name token of '1C-A0-91-87-7D-12-CA-03' but got '50-CE-BF-1C-CE-B9-D0-5E'. The weaver needs to update to at least version 3.0 of FodyHelpers.