Re: [Meinds-developers] Aspect oriented framework, first go

[Dmitri C. <di...@bi...>]

got another query...

in CallLog, you have

   public Object invoke(Object proxy, Method method, Object[] args)
      throws Throwable
   {
      // Log call
      if (!method.getDeclaringClass().equals(Object.class))
                                             ^^^^^^^^^^^^

shouldn't it be

   public Object invoke(Object proxy, Method method, Object[] args)
      throws Throwable
   {
      // Log call
      if (!method.getDeclaringClass().equals(getObject().getClass()))
                                             ^^^^^^^^^^^^^^^^^^^^^^
?  it seemed that the log methods weren't really coming out that
usefully so I had a look...  this change makes them look quite odd in
places, my thoughts are that this is due to the implicit toString() calls
going through the proxy, and hence through the logger... I'm assuming that
this sort of logging probably wouldn't be done via an interceptor, the
logging you'd be interested at the interceptor would be business logging
yes?

anyway, still reading, still smiling (o:

cheesr
dim

On Thu, 29 Nov 2001, Dmitri Colebatch wrote:

> On Wed, 28 Nov 2001, Rickard [ISO-8859-1] =D6berg wrote:
>=20
> > I have now finished the first working version of an Aspect Oriented=20
> > Programming (AOP) framework. It is very simple, yet extremely powerful.=
=20
> > I should be very useful as the base for the object model of Meinds.
>=20
> hehe... yes I agree... you are very useful for the object model for Meind=
s
> (o:  if only someone had thought to not make you a singleton!
>=20
> > Individuals have the ACL, Member, and User aspects attached to them. Th=
e=20
> > basic object itself that these are attached to is a simple string (the=
=20
> > id). Hence, the object itself does not provide much functionality,=20
> > except toString(), hashCode(), and equals() implementations (from=20
> > java.lang.String).
>=20
> I've had a good look through, and am pretty comfortable (I think) with th=
e
> flow of events and stuff (IntelliJ + Ctrl-B works wonders :), and surpris=
e
> surprise have a couple more questions related to state. =20
>=20
> I _think_ I now see why state hasn't really been an issue... each aspect
> can simply control their own state - yeah?  as the implementation of ACL
> does... so as far as persistence is concerned, that is where that would
> occur as well...  in UserImpl you have getName() simply returning the
> resource id - in reality UserBuilder will load an object from persistent
> store, and that is where the name would come from, yes?
>=20
> one other little thing here, the term Builder, as I understand GoF use it=
,
> is a stateful throwaway object that you use to incrementially build
> something... aren't the Builders more like Factories?  or am I missing
> something?
>=20
> what is next on the list then?  I'd be very keen in doing something here,
> and feel like I understand what you're doing in the code... I suppose a
> good start would be doco - do you have any thoughts on what structure the
> documentation should take (in terms of a toc)... I figure if I started
> there I would (a) ensure that I'm not completely missing something - or a=
t
> least have it corrected by you, and (b) get the necessary evil of doco
> started at an early point...  thoughts?
>=20
> cheers
> dim
>=20
>=20