The Artima Developer Community
Sponsored Link

.NET Buzz Forum
I support AOP not AOP stupid

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Jonathan Crossland

Posts: 630
Nickname: jonathanc
Registered: Feb, 2004

Jonathan Crossland is a software architect for Lucid Ocean Ltd
I support AOP not AOP stupid Posted: Jul 1, 2004 3:27 PM
Reply to this message Reply

This post originated from an RSS feed registered with .NET Buzz by Jonathan Crossland.
Original Post: I support AOP not AOP stupid
Feed Title: Jonathan Crossland Weblog
Feed URL: http://www.jonathancrossland.com/syndication.axd
Feed Description: Design, Frameworks, Patterns and Idioms
Latest .NET Buzz Posts
Latest .NET Buzz Posts by Jonathan Crossland
Latest Posts From Jonathan Crossland Weblog

Advertisement


The can of worms are wriggling on the floor.
I am tremendously happy that Eric has brought AOP up again.

I felt a bit silly (stupid really), going on For and Against AOP, so I thought I'd explain.
I believe that AOP is a fine education, but not mainstream.
I believe in AOP, but I dont. I do not like the weaving of code in and out of my code, not knowing what is going on. The compiler would also have to change its spots.

I would not like to see language changes like aspect, pointcut, in AspectJ
over designed and too complicated for limited benefit. But I have been advocating a form of it for a long time. Read here, here and here, here and here.

MTS (I believe Pat Helland was significant) and COM+, gave us a higher power. From roles, transactions and sheer delight, I wrote my first book, Windows DNA with many other great people.

I truly believed that the world was getting better.

With Reflection, CodeDOM and more it was for a while, until ContextBoundObject deflated my dreams by making me a plumber - again.

I dont want to see the code weaving, static or dynamic, but I do want to snapin, observe and intervene.

Good reasons for "hooking in", "intervention", "AOP-like behaviour" are for

Structural Architectural elements - such as logging, exception management, security, roles, customizations based on roles etc. The key though is that everything that we dont actually want to see entangled with the normal logic of the code exists out of sight.

Further, the Factory Method, Singleton and Observer patterns are in my opinion (at the top of my head), candidates for moving down lower into the plumbing. How far? probably not compiler level, although the compiler might need to set it up correctly on the plate for the Runtime.

As I mentioned in a comment on Eric's post, I like an Intervention philosophy.
Code is sometimes better to illustrate so here is my attempt at some of the syntax.

notes on the psuedo code below,
If no Attribute is found then no overhead is incurred. Nothing happens
No ContextBoundObject to derive from.
I can hook in, from inside my Assembly (MyObject), or outside (MyOtherObject)
I believe that intervention, could be done in the compiler by altering the Symbol Graph, and by altering the current ContextBoundObject behaviour currently in the framework.
using System;
using System.Runtime.CompilerServices;
using System.Runtime.Intervention;

namespace MyNamespace
{
    
    //uses the MyIntervention Type shown below
    [DemandInterventionAttribute(typeof(MyIntervention))]
    public class MyObject : MyOwnBaseClassIfIWantIt
    {
        public MyObject()
        {
            this.SomeMember +=    new MyOtherObject.SomeMember(SomeMember_Executed);
        }

        public string SomeMember()
        {
            //possibility of creating an instance using a context
            ObjectContext ctx = new ObjectContext();
            MyOtherObject myOtherObject = Activator.CreateInstance(MyOtherObject,ctx);
            //do what I wish
            return "some result";
        }

        public void SomeMember_Executed()
        {
            //Do something
        }
    }

    //MyInterventionBase Type loaded
    //from configuration file, allowing plugin like behaviour
    [DemandsInConfigurationAttribute()]
    public class MyOtherObject
    {
        public MyOtherObject()
        {
        }

        public string SomeMember()
        {
            return "some result";
        }

        
    }

    public class MyIntervention : InterventionBase // IMessageSink
    {
        public MyIntervention()
        {    
        }

        //I can override members on IMessageSink if I desire (ie. Pre/PostProcessMessage)
        
        //gets sets and instance of - I can alter if I wish
        public object GetInstance (ObjectContext ctx){}
        public object SetInstance (ObjectContext ctx){}

        public IMethodReturnMessage InvokeMember(IMessage msg, ObjectContext ctx)
        {
            return base.InvokeMember(msg);
        }
        public IMethodReturnMessage InvokeMember(MethodBase methodBase, ObjectContext ctx)
        {
            return base.InvokeMember(methodBase);
        }
    }

}

Read: I support AOP not AOP stupid

Topic: Mono 1.0 Previous Topic   Next Topic Topic: Luke Hoban - C# Express PM is blogging

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use