AOP

[Peter Morris]

Hi all

You know what I'd like to see? I'd like to see compiler support for AOP.
Take PostSharp as an example, it hooks into the build process and modifies
your binary output


[Log]
public void DoSomething()
{
}

adds logging to the DoSomething method. It is also possible to add
interface support

[Bindable]
public class Person
{
}

adds INotifyPropertyChanged etc.


I would love to see AOP support in the compiler because when adding
interface support you cannot do something like this


someObject.Method_Expecting_IContact(person);

because IContact is added to Person after compilation, so this would fail.
With proper IDE support I'd be able to do stuff like this

[BusinessObject]
public class Person
{
public string Name { get; set; }
}

and then also be able to write code like this

Person p = new Person();
string name = (string)
p.GetPropByIndex(Person.PropertyIndices.Name);

It's not the best example in the world, but the point is that code-insight
could complete code as if I had written it, and I'd be able to write code
that assumed I had manually written it out rather than merely using an
attribute etc. I think this would be great. Not having compile time
support for AOP decorated stuff is one of the weak points of AOP in my
opinion, it's not a spoiler or anything but it certainly would be great if
it were there!



Pete

 

[Peter Morris]

Obviously I am in a minority here.

 

[Marc Gravell]

It sounds like you actually want fancy macros...?

string name = (string)
p.GetPropByIndex(Person.PropertyIndices.Name);

just... why? what is wrong with string name = p.Name?

Without an explicit order (which C#/.NET does not have) it is brittle to
use numeric indices as it can go to heck when they change (if that is
what is going on - if it is an enum then fine).

But this is a lot more than just AOP (which adds implementation to
existing methods) - this is full dynamic code generation (courtesy of
the weaver). For my money, the public API should be the same with or
without the attributes; if the AOP core wants to inject extra code, then
fine (I actually like post#) - but I think the generated PropertyIndices
approach is dangerous in that it makes a fundamental change to the API.
Adding supprt for interfaces (such as notification) I can probably
forgive if it uses explicit implementation - i.e. it doesn't change the
public API. In short I'd want code compiled with an attribute to also
compile without it - although obviously the injected code would be missing.

So in my ideal world, there is nothing *for* the compiler to have to
support; the weaver might be busy, but that already exists and works.

Marc

 

[Marc Gravell]

is dangerous in that it makes a fundamental change to the API.

Adding supprt for interfaces (such as notification) I can probably
forgive if it uses explicit implementation

Of course, even this would break an implicit cast... even more reason
(perhaps) to not support it at compile time.

Marc

 

[Peter Morris]

just... why? what is wrong with string name = p.Name?

Nothing at all. My example was fictitious. My post was about development
time support for AOP. As another example look at this...


public interface ISomeInterface
{
........
}


[SomeInterface]
public class Person
{
}


the SomeInterfaceAttribute could not only declare ISomeInterface against the
Person class but also add a common implementation too. Then when I have a
method elsewhere expecting ISomeInterface I can do this


Person person1 = new Person();
SomeObject.DoSomething(person1);


At the moment VS would tell me that I cannot cast Person to ISomeInterface,
this is because I have not implemented it during development and it is woven
in by PostSharp afterwards. I am saying it would be nice if we could add
functionality to classes in such a way *and* to be able to see code-insight
for those added features and also have the compiler recognise them, all as
if I had written them in manually.

At the moment I can implement common behaviour using aggregation.....

public interface ISomeInterface
{
void DoSomething();
}

public class SomeInterfaceImpl : ISomeInterface
{
void ISomeInterface.DoSomething()
{
}
}

public class Person : ISomeInterface
{
private SomeInterfaceImpl SomeInterfaceImplementor =
new SomeInterfaceImpl();

void ISomeInterface.DoSomething()
{
SomeInterfaceImplementor.DoSomething();
}
}

but this is a lot more code. But don't just think of it for saving writing,
think of how useful IDE + Compiler support for AOP would be. I think it
would be great, especially for frameworks. Take EntityFramework as an
example
http://www.sitechno.com/Blog/IntroducingEntityFrameworkContribEasyIPocoImplementationV01.aspx



Pete



Pete