[self-interest] Aspect oriented and self

[Jecel Assumpcao Jr]

On Wednesday 21 August 2002 10:13, Steve Dekorte wrote:
> On Wednesday, August 21, 2002, at 01:14  AM, Thorsten Dittmar wrote:
> > For example, Self has mixins and dynamic inheritance with this two
> > mechanisms you can solve a lot of the AOP stuff.
>
> Yes, I've thought the same thing. Of the AOP descriptions I've read,
> it all sounds like just adding some extra parent links in Self would
> accomplish the same thing.

And James McCartney suggested Lisp-like macros.

I think AOP is an excellent idea and that you haven't understood the 
full scope of it if you think such simple solutions would do the same 
thing. They could certainly handle one or another AOP example, but 
would not deal with the full idea. Of course, neither does AspectJ as 
Steve pointed out in the part I deleted.

And as I was explaining to Albertina the other day, doing things at the 
slot level isn't fine grained enough for true AOP.

> [....] I don't see how the one feature
> AspectJ adds to Java makes a significant contribution to the
> solution. Why not go farther and say "there's all sorts of other
> assumptions that inflexible systems force upon your abstractions, so
> let's see what we can do with highly flexible systems"?

This is the key - David Ungar's ECOOP'95 talk described the American and 
Scandinavian schools of object programming as "cowboys" and "cabinet 
makers". Dynamic languages are better for exploring while static 
languages are better for modeling.

Well, AOP is a fantastic way to add flexibility to your model. We don't 
need that flexibility in Self since we can change things *after* the 
program is already running! We don't have to think of everything in 
advance. All our tools are still with us when the need to change 
becomes obvious (when the weavers and compilers of static systems have 
done their jobs and left a long time ago).

So the short answer is that we don't have AOP in Self but don't really 
want it either.

Some things just don't mix. Take AOP and eXtreme Programming, for 
example. XP is obviously for cowboys: "we fix things as we go along". 
One of its most important rules is "don't program today for what you 
think you will need tomorrow - don't leave hooks for future code" and 
yet that describes exactly what AOP is! You can't always stuff all good 
ideas into a single project.

-- Jecel