A fresh look at AOP - Use classes to define behavior, use aspects to compose behavior

A fresh look at AOP, by Carlo Pescio (http://www.aspectroid.com)

"Aspectroid is an exploration of the design space, moving beyond conventional object oriented design and further into the aspect-oriented expanse. [...] to best combine OOP and AOP, [...] AOP is a powerful, yet largely misunderstood and misrepresented paradigm."

"I started this project with a design vision in my mind, and a set of hypothesis that I wanted to test. My vision was to use aspects to improve object-oriented design, or more exactly statically-typed object-oriented design, so that I could have the benefits of static typing, but also enjoy the flexibility usually associated with dynamic languages like Smalltalk. Actually, I wanted to move one step forward, and aim for a degree of compositionality beyond what is normally possible with OOP alone. Behind that vision, I had a few, relatively straightforward goals:

- Align the architecture with the nature of the problem
- Allow for extension and contraction of application-level concerns

[...]

"AOP goals: Use aspects to separate application concerns, as opposed to what we commonly see in literature, where technological concerns like logging, exception handling, etc. are usually addressed."

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Weird. I'm working on

Weird. I'm working on something more like "use classes to define behavior, use machine learning to compose behavior."

Anywhere to read about that?

That sounds intriguing, do you have anything to share about it yet?

No not yet. I'm still

No not yet. I'm still working on the ML experience. What I have found is that internally, some neural nets develop very object-oriented generalizations; e.g. internalize coke as "0110110101" and pepsi as "0101110101". My idea is to somehow represent an object oriented type as a bit vector: a concrete type that completes an abstract type is would simply has more bits turned on. Then given any abstract type t, we can develop a net that can propose concrete types to complete it (basically composing classes to implement abstract gaps).

But there is a very steep hill to climb.