Ayende @ Rahien

Ayende Rahien commented on Avoiding Invasive API design

Tue, 25 Mar 2008 15:18:54 GMT

Invasive in this context means that the usage of library/framework means that I have to modify parts of my code.

Benny Thomas commented on Avoiding Invasive API design

Tue, 25 Mar 2008 12:33:44 GMT

Could someone explain the word invasive in this context. regards Benny

RhysC commented on Avoiding Invasive API design

Wed, 19 Mar 2008 17:14:52 GMT

this just remindes me of Object Builder... the fact that just by looking at the properties of a class you can tell that application is using a particular form IoC (Object Builder) makes me very uneasy...

Ayende Rahien commented on Avoiding Invasive API design

Wed, 19 Mar 2008 15:28:37 GMT

LOL. Yes, IoC is the way I would go. In general, I would say that I want IVersionProvider from the IoC and let it deal with it. this is for a solution that cannot assume IoC

Stefan Wenig commented on Avoiding Invasive API design

Wed, 19 Mar 2008 14:53:30 GMT

OMG, Customer and Customers confused me again. I just read it again, the [SvnVersion] attribute is in Customer (not in the end point), so you're perfectly right - it's invasive. But still, would that not be easier to achive using an IoC container (probably configured by code though)? Passing a factory type as a generic argument might be a bit harder to read, especially if the reader is familiar with IoC. Speaking of IoC, it's funny how this reminds me of Spring itself: AFAIR they refuse to have invasive attributes for default classes on their type members, but rather have the user code seperate config classes if they want to configure by code. So if you'd use Spring to configure your IVersionProviderFactory, you'd be meta-uninvasive ;-)

Stefan Wenig commented on Avoiding Invasive API design

Wed, 19 Mar 2008 14:51:45 GMT

Markus, DP2 is not an IoC container. It does have an mixin API though, but it's a bit awkward to use and does not bring the full power of mixins. After all, it's more or less a byproduct of the proxy generation stuff of DP. Compare this to what you can do with C++ mixins, there's a lot more to it than just delegating interface members to other objects. (Or, again, read my link.) I quickly read up on Windsor facilities. As far as I can tell, they are not really an IoC feature, but they might enable you to code a mixin facility. But that would probably be based on DP's stuff, and we made a decision long ago to not build our mixin stuff on DP for a reason, so you might not be able to go all the way using this approach. Anyway, I'd like to see the code! Can you ping me on stefan dot wenig at rubicon dot eu when you've got your blog post finished?

Ayende Rahien commented on Avoiding Invasive API design

Wed, 19 Mar 2008 14:36:51 GMT

I need to tell that endpoint what the revision property is. The question is how to do it. I can do it with an attribute (invasive) or allow non invasive approaches

Stefan Wenig commented on Avoiding Invasive API design

Wed, 19 Mar 2008 14:31:00 GMT

Ayende, you're right, I failed to notice that Customer and Customers are two different classes. But in this case I don't understand how the attribute solution you initially discard would be invasive. After all, you wouldn't have to touch the domain class if your end point changed, would you?

Ayende Rahien commented on Avoiding Invasive API design

Wed, 19 Mar 2008 14:21:22 GMT

Markus, This sample has nothing to do with NH/AR. It is simple here to make a point about invasive approaches

Ayende Rahien commented on Avoiding Invasive API design

Wed, 19 Mar 2008 14:20:43 GMT

Stefan, Customers is an end point in this regard, it is not doing actual useful work on its own. Think about it like System.Windows.Forms.Control.

Ayende Rahien commented on Avoiding Invasive API design

Wed, 19 Mar 2008 14:19:32 GMT

Adam, There is no relation to AR. It is merely a way to demonstrate that. NHibernate can certainly be handled this way, since is it entirely non invasive. AR is an invasive layer that makes working with NH much easier.

Markus Zywitza commented on Avoiding Invasive API design

Wed, 19 Mar 2008 13:18:30 GMT

Stefan, DP2 allows the creation of Interface-proxies, thus adding the interface at runtime. Although AFAIK mixins are not implemented in DP2 yet, it is possible to emulate mixins by using an interceptor that redirects calls to the proxy to either the base object or the mixin object. Since facilities can add interceptors to components without explicit configuration, it is possible to use Windsor for that task. I'm preparing a blog post on that topic (I started it when Ayende complained about C#'s inability of creating mixins, but I don't have much time currently^h^h in general).

Stefan Wenig commented on Avoiding Invasive API design

Wed, 19 Mar 2008 10:42:10 GMT

Makus, I'm not sure if I understand you correctly, but I think this is not something that IoC can do. If you specify IVersioned at compile-time, you also have to implement it manually. But if you're interested in mixins, do have a look at the link I posted. If you know an IoC container that enables similar stuff, I'd like to hear about it!

Markus Zywitza commented on Avoiding Invasive API design

Wed, 19 Mar 2008 10:02:48 GMT

@Stefan - I meant the following: Replace Versioned with IVersioned, so you don't need a base class and attach the functionality of Versioned by using proxies (with IoC preferably)

Stefan Wenig commented on Avoiding Invasive API design

Wed, 19 Mar 2008 09:43:35 GMT

I wonder if it wouldn't be easier to use IoC to inject whatever versioning provider you'd want. That way, you would not have to waste a base class, of which there can only be. So this could get a bit more complicated if you wanted to apply it to more than one feature. (@Markus - mixins could be another solution, but I don't see how this is a way of doing mixins. Here's ours: http://www.re-motion.org/blogs/team/archive/2008/02/20/introducing-mixins-finally.aspx. You could probably even use it to provide several features like Versioned<,>, but I'd still try IoC first.)

Adam B commented on Avoiding Invasive API design

Wed, 19 Mar 2008 08:53:51 GMT

@Markus: I was thinking *exactly* the same thing. I use attributes all over the place. @Ayende: Would this translate for [Property] i.e. could ActiveRecord/NHibernate using attributes theoritically be re-written this way and would it even be a good idea?

Colin Jack commented on Avoiding Invasive API design

Wed, 19 Mar 2008 08:07:23 GMT

Interesting stuff. Ayende Annoyance Principal, AAP. Gonna start using that.

Markus Zywitza commented on Avoiding Invasive API design

Wed, 19 Mar 2008 07:52:28 GMT

Nice example of doing Mixins with C# 2.0. But now please explain the difference of [SvnVersion] and [Property]