Ayende @ Rahien

Lars Corneliussen commented on Review: Umbrella project

Thu, 19 Jun 2008 08:17:15 GMT

Hi, thanks for the review! I agree with you, Ayende, that IMessage is a missleading name. For ISources i have an implementation for ThreadLocal here: http://startbigthinksmall.wordpress.com/2008/04/24/nice-free-and-reusable-net-ambient-context-pattern-implementation/ For personal use i also abstracted Session, Application and HttpContext.Items in a comparable manner. I would love a post from Francois explaining all the different blocks and his approaches in the same style as you did.

Francois Tanguay commented on Review: Umbrella project

Thu, 05 Jun 2008 22:55:18 GMT

@Frans: They aren't mutable expression trees per se. It's more of an Expression Tree Builder. @Yann: It's not YET documented. It is on the way. We were challenged to get something out asap so we can get some valuable insight and feedback on what community liked about it.

Yann Trevin commented on Review: Umbrella project

Thu, 05 Jun 2008 18:45:58 GMT

Interesting. I never heard about the Umbrella project before. I just had a look at the code (poorly documented by the way) and it seems to me that some portions would well deserve to be part of the next version of the class library; in particular the extension methods for the generic collections and the enumerable interfaces, which I find especially useful.

Frans Bouma commented on Review: Umbrella project

Thu, 05 Jun 2008 08:18:05 GMT

"Linq expressions are immutable, which make it a harder to build them. Umbrella solve this by giving us editable expressions, which are builders on top of normal extensions. Nice." I think this is a step in the wrong direction. Linq expressions are immutable for a reason: you can process them in parallel, as immutable objects don't have threading issues. Another, more theoretical reason is that a function returns a value, which is either the same value it received, or a new one. Mutable expression classes seem like the thing you want almost immediately when you start with linq expressions, as sooner or later you have to change something in an expression but as they're immutable, you've to make a copy, a new instance, which of course is a pain if you have references to that expression instance you want to mutate. The thing is though: if you run into such a situation, it's a signal the code handling the expressions isn't good. As the appropriate way to handle expression objects/trees is to traverse them, and replace the subtrees you recognize with another expression, effectively a tree reduction system. In such a system, if done properly, you never run into a situation where you need to alter an existing instance, you can always simply create a new one with the value changed, replacing the original. In practise it's very hard to achieve such a system with Linq expression trees however, due to the fact it uses parameters to refer to subtrees elsewhere in the expression tree. This means you need to make clones of these subtrees replacing the parameters, OR, you have to keep track of already handled subtrees. Nevertheless, my experience is that opting for mutable expression objects is not really what you want, as it leads to more errors. I know because my own expression objects were mutable at first and you run into bugs which are hard to track down.

Andre Loker commented on Review: Umbrella project

Thu, 05 Jun 2008 07:31:49 GMT

Thanks Ayende for the in-depth review. Some of the features sound really cool (especially because of them being simple yet useful). I'll definitively have a look at Umbrella. Regards, Andre

Francois Tanguay commented on Review: Umbrella project

Wed, 04 Jun 2008 19:55:11 GMT

Cool. ThreadLocalSource uses a ThreadStatic dictionary as well. And HttpContextSource (not sure it's checked in yet) relies on HttpContext just as yours. I would then use a SourceChain or something to chain them together. My point was that there are other implementations (Lazy, WeakReference, ...) of ISource and that's why I tried to abstract an interface for all of those.

Ayende Rahien commented on Review: Umbrella project

Wed, 04 Jun 2008 19:46:31 GMT

Take a look here: https://rhino-tools.svn.sourceforge.net/svnroot/rhino-tools/trunk/rhino-commons/Rhino.Commons.Clr/LocalDataImpl/LocalData.cs

Francois Tanguay commented on Review: Umbrella project

Wed, 04 Jun 2008 19:37:53 GMT

Meaning? virtual methods and proxies?

Ayende Rahien commented on Review: Umbrella project

Wed, 04 Jun 2008 19:33:13 GMT

Francois, Thanks for respond so quickly. That explain why I was at a loss to get them, I have a drastically different way of solving those

Francois Tanguay commented on Review: Umbrella project

Wed, 04 Jun 2008 19:11:46 GMT

Ayende, What a great review! I'll make sure to delve into the details of your questions in more details as soon as I have some free time. If YOU're not understanding some of the code, I better find a way to make it simpler as not many will be able ;) Documentation is on the way. It's always like that. You launch a project, then start a new client mandate and end up not having much time for documentation efforts. But for what it's worth: Sources: Think of it as something implementing IGetSet. It is a placeholder for a reference (just as WeakReference is). It can be Weak, Lazy, ThreadLocal. It can come from AppSettings, From an existing reference, ... public interface ISource { T Value { get; set; } } So instead of having to deal with Thread Local Data Slot, you just new up a ThreadLocalSource and you got thread local variables. Same thing with LazySource. instead of having a property getter like: public class Foo { private Bar bar; public Bar Bar { get { if (bar == null) { bar = Factory.CreateBar(); } return bar; } } } you can have: public class Foo { private ISource bar = new LazySource(Factory.CreateBar); public Bar Bar { get { return bar.Value; } } } Values are exactly the same thing as Sources, except they expose IMessage Get and Set properties. This allows binding between 2 values as you're able to observe when the value has changed.

Ayende Rahien commented on Review: Umbrella project

Wed, 04 Jun 2008 19:10:19 GMT

Roger, thanks, fixed.

Justin Etheredge commented on Review: Umbrella project

Wed, 04 Jun 2008 18:24:22 GMT

@Roger Yep, Memoization is simply caching function results based on arguments. What is being shown is currying, since you are taking a method of multiple arguments and turning it into a series of single argument methods. If he were to pass more than one argument to any of the resulting methods then it would be considered "partial application" instead of currying. Currying specifically deals with single parameter methods.

Roger Alsing commented on Review: Umbrella project

Wed, 04 Jun 2008 17:59:28 GMT

I might be way off here since I havent looked at the code. but: >>It is also called memoization<< That sample you posted looks very much like _currying_. supplying one or more arguments to a function that returns a function untill the entire argument list have been passed. And the last function returns the same result as you would have gotten if you passed all the arguments at once. Memoization is something completely different AFAIK.