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]

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/Introdu...tationV01.aspx

Pete

Pete