[aosd-discuss] can you have interception w/o aop?
Roger Johansson
roger.johansson at compona.com
Thu Apr 6 02:03:26 EST 2006
Ok, I don't feel that Ive got any real clear answers to the questions yet.
1) Can you have interception w/o aop?
Show me a pseudo code example of interception where the interception code is
not modular in any way
If your base code manually triggers some event , its not interception , then
its delegation, right?
Atleast for me interception is when the base (source) code is ignorant of
the interception mechanism.
and if the base source code is ignorant of that mechanism the design is
modular, right?
thus, whenever you use interception you get AOP?
another question that arise from your answers.
2) does the aspects have to be ignorant of the base code?
In that case , would a "Lazy load" aspect that "knows" what private fields
of the subject to load data into not be considered AOP? (because it knows
things about its target)
//Roger
----- Original Message -----
From: <discuss-request at aosd.net>
To: <discuss at aosd.net>
Sent: Wednesday, April 05, 2006 8:40 PM
Subject: discuss Digest, Vol 31, Issue 2
> Send discuss mailing list submissions to
> discuss at aosd.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://aosd.net/mailman/listinfo/discuss_aosd.net
> or, via email, send a message with subject or body 'help' to
> discuss-request at aosd.net
>
> You can reach the person managing the list at
> discuss-owner at aosd.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of discuss digest..."
>
>
> Today's Topics:
>
> 1. Re: can you have interception w/o aop? (Kevin Sullivan)
> 2. Re: can you have interception w/o aop? (Cristina Videira Lopes)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 5 Apr 2006 14:26:47 -0400
> From: "Kevin Sullivan" <sullivan.kevinj at gmail.com>
> Subject: Re: [aosd-discuss] can you have interception w/o aop?
> To: "Cristina Videira Lopes" <lopes at ics.uci.edu>
> Cc: AOSD Discuss Mailing List <discuss at aosd.net>
> Message-ID:
> <c798e1ec0604051126g26c06d4cr24e6156999c22654 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> There are a few misconceptions about our paper and our definitions
> embedded in the note below. Let me see if I can clear them up.
>
> On 4/5/06, Cristina Videira Lopes <lopes at ics.uci.edu> wrote:
>>
>>
>>
>> > -----Original Message-----
>> > To briefly quote from the paper:
>> >
>> > "We say that a design or a part of a design is modular
>> > if its elements
>> > do not depend on each other (although they may depend
>> > on external
>> > design rules that serve to decouple them)."
>>
>> Maybe I'm interpreting this out of context, but this is the strictest
>> definition of modularization that I have ever seen...
>>
>> Under this definition, my laptop doesn't seem to be a modular system. For
>> example, the main body depends on both the power cord and the battery to
>> function properly. There is no design rule that decouples the power cord
>> and
>> the battery from the main body -- the computer industry seems to make a
>> point in creating an endless variety of power cords and batteries that
>> are
>> specific to every laptop model out there.
>
>
> The misconception here is that independence of the design tasks (modulo
> the
> design rules) equites to functional independence of the designed
> components
> in
> the actual artifact. That's not true. A laptop obviously depends on the
> presence
> of power to work. However, that doesn't mean that the engineering group
> that's
> tasked to design the motherboard depends on decisions made by the group
> that
> is tasked to design the power cord, or vice versa. Appropriate design
> rules--rules
> that modularize the design and the design tasks--allow these design tasks
> to
>
> proceed independently. What do the design rules look like in this case?
> They
>
> specify power levels and physical plug configuration (and probably other
> things:
> I'm not an electrical engineer and I haven't actually studied this kind of
> interface).
> Once the cord designers know these parameters, they can go ahead and make
> their design decisions independently of those being made by the
> motherboard
> group ( e.g., they can select and change their decisions about wire gauge
> and
> conducting material without having to coordinate with the motherboard
> group);
> and the laptop "main body" group can go ahead and make decisions without
> ever having to coordinate with the power cord design group (e.g., the main
> body
> group can make decisions about how to allocate the available power to
> devices
> without ever having to talk to the power cord designers, precisely because
> there
> is a decoupling design rule in place: "here's how much power (a) the cord
> must
> supply, (b) the body can consume").
>
> You may say, of course, that there are different design rules decoupling
> the
>> power cord and the battery for every laptop model. Well, yes, but this
>> seems
>> to trivialize the concept of design rule. Applying this to software, it
>> would mean that you go from a non-modular to a modular design simply by
>> proliferating interfaces, with the sole purpose of "decoupling" every
>> pair
>> of interacting components.
>
>
> The misconception here is that our paper advocates indiscriminate
> decoupling
> of
> design decisions. That is not true. We very clearly state criteria for
> decomposing
> design into modules. At a technical level, one does this by using a
> generalized
> information hiding approach in which decisions are decoupled in a
> principled
> way
> for a variety of reasons, e.g., for parallelism in design, abstraction
> from
> complexity,
> and ease of evolution. At a business level, one does this in part driven
> by
> the goal
> of increasing the net (financial) options value of a design -- (net of the
> direct and
> opportunity costs of modularity). A cursory reading of the paper will make
> these
> points clear, and the the underlying theories and literature are
> adequately
> cited.
>
> While we can do that, those interfaces / design
>> rules / decoupling are an illusion, they serve no real purpose, because
>> some
>> implementation dependencies are an inherent part of the problem
>> formulation.
>>
>> There are many purposes for modularization, not just the ADT-ing purpose,
>> which is what this definition seems to imply.
>
>
> The misconception here is that our notion of design rules is equivalent to
> the
> imposition of an abstract data type interface. That is not true. In fact,
> the main
> focus of the paper is on a new and very non-ADT-like concept of interface
> and
> of modularity for AOP, which in later work (see Griswold et al., IEEE
> Software,
> January/February 2006) we called the crosscut programming interface or
> XPI.
> The power core example should also make clear that design rules in our
> view
> are not equivalent in our conception to ADT-based API's. In the power cord
> case,
> the rules stipulate power levels, physical form factors, and probably
> other
> key
> properties, such as corrosion resistance under electrical current at the
> contact
> points.
>
>
> In the case of my laptop, it's
>> very convenient to dettach the power cord and the battery from the main
>> body
>> when I travel, even if they only work for my laptop and no other laptop
>> in
>> the world. The battery-as-module is particularly convenient, as its
>> performance degrades over time; it's good to be able to replace it with
>> another one of exactly the same type, rather than having to buy a new
>> laptop
>> when the battery dies.
>
>
> The misconception here is that modularity in design and modularity in use
> are the
> same. That is not true. It's possible to have neither, either or both. A
> completely
> coupled design task could produce an artifact that is modular in use. A
> modular
> design task could produce an artifact that is completely integral in use.
> Etc. Of
> course in practice there is often a close alignment between the modular
> structure
> of the design and design task and of the artfact-in-use (as in the PC
> industry, in
> the audiophile industry, etc).
>
> In the computer industry, non-ADT-ing modularizations work to the
> financial
>> advantage of market leaders... "Buy a complete modular system where some
>> modules may break; you can get a replacement from us only, at $50!"
>> Standardizing the technology of power cords and batteries -- technically
>> simple -- would disrupt the market.
>>
>> Establishing design rules in a modular design has effects which you may
>> or
>> may not want. But that doesn't mean that a system isn't modular until all
>> of
>> its components depend only on design rules.
>
>
> The misconception here is that that is what we said :-) That's not true.
> What
> we said is the following: "We say that a design or a part of a design is
> modular
> if its elements do not depend on each other (although they may depend on
> external design rules that serve to decouple them)." We stand by this
> definition.
>
> Best regards,
> Kevin Sullivan
> University of Virginia
>
> I would claim that the whole art
>> of modular design is in deciding what is *and what isn't* a design rule.
>> The
>> proliferation of trivial design rules can have a negative effect on the
>> value of the design.
>>
>> -Crista
>>
>> PS. ADT = Abstract Data Type, roughly, an interface that can have many
>> implementations.
>>
>>
>> __________________________________________________
>> AOSD Discuss mailing list - discuss at aosd.net
>> To unsubscribe go to http://aosd.net
>>
>> Check out the AOSD.net Wiki: http://aosd.net/wiki
>>
>
>
>
> --
> Kevin Sullivan
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://aosd.net/pipermail/discuss_aosd.net/attachments/20060405/b4a4f581/attachment-0001.htm
>
> ------------------------------
>
> Message: 2
> Date: Wed, 5 Apr 2006 11:38:59 -0700
> From: "Cristina Videira Lopes" <lopes at ics.uci.edu>
> Subject: Re: [aosd-discuss] can you have interception w/o aop?
> To: "'Kevin Sullivan'" <sullivan.kevinj at gmail.com>
> Cc: 'AOSD Discuss Mailing List' <discuss at aosd.net>
> Message-ID: <200604051838.k35IcxtL012038 at scanner2.ics.uci.edu>
> Content-Type: text/plain; charset="us-ascii"
>
> So many misconceptions! :-)
> I could reply by saying that there is an equal number of
> mis-misconceptions
> in the note below, including the a narrow concept of ADT, but let me zoom
> in to the core of the matter: the definition of modular system.
>
>> The misconception here is that that is what we said :-) That's not true.
> What
>> we said is the following: "We say that a design or a part of a design is
> modular
>> if its elements do not depend on each other (although they may depend on
>> external design rules that serve to decouple them)." We stand by this
> definition.
>
> I said the following: "Establishing design rules in a modular design has
> effects which
> you may or may not want. But that doesn't mean that a system isn't modular
> until
> all of its components depend only on design rules." I stand by my comment.
>
>
> _____
>
> From: Kevin Sullivan [mailto:sullivan.kevinj at gmail.com]
> Sent: Wednesday, April 05, 2006 11:27 AM
> To: Cristina Videira Lopes
> Cc: Eric Eide; AOSD Discuss Mailing List
> Subject: Re: [aosd-discuss] can you have interception w/o aop?
>
>
> There are a few misconceptions about our paper and our definitions
> embedded in the note below. Let me see if I can clear them up.
>
>
> On 4/5/06, Cristina Videira Lopes <lopes at ics.uci.edu> wrote:
>
>
>
>> -----Original Message-----
>> To briefly quote from the paper:
>>
>> "We say that a design or a part of a design is modular
>> if its elements
>> do not depend on each other (although they may depend
>> on external
>> design rules that serve to decouple them)."
>
> Maybe I'm interpreting this out of context, but this is the strictest
> definition of modularization that I have ever seen...
>
> Under this definition, my laptop doesn't seem to be a modular system. For
> example, the main body depends on both the power cord and the battery to
> function properly. There is no design rule that decouples the power cord
> and
> the battery from the main body -- the computer industry seems to make a
> point in creating an endless variety of power cords and batteries that are
> specific to every laptop model out there.
>
>
> The misconception here is that independence of the design tasks (modulo
> the
> design rules) equites to functional independence of the designed
> components
> in
> the actual artifact. That's not true. A laptop obviously depends on the
> presence
> of power to work. However, that doesn't mean that the engineering group
> that's
> tasked to design the motherboard depends on decisions made by the group
> that
> is tasked to design the power cord, or vice versa. Appropriate design
> rules--rules
> that modularize the design and the design tasks--allow these design tasks
> to
>
> proceed independently. What do the design rules look like in this case?
> They
>
> specify power levels and physical plug configuration (and probably other
> things:
> I'm not an electrical engineer and I haven't actually studied this kind of
> interface).
> Once the cord designers know these parameters, they can go ahead and make
> their design decisions independently of those being made by the
> motherboard
> group ( e.g., they can select and change their decisions about wire gauge
> and
> conducting material without having to coordinate with the motherboard
> group);
> and the laptop "main body" group can go ahead and make decisions without
> ever having to coordinate with the power cord design group (e.g., the main
> body
> group can make decisions about how to allocate the available power to
> devices
> without ever having to talk to the power cord designers, precisely because
> there
> is a decoupling design rule in place: "here's how much power (a) the cord
> must
> supply, (b) the body can consume").
>
>
>
> You may say, of course, that there are different design rules decoupling
> the
> power cord and the battery for every laptop model. Well, yes, but this
> seems
>
> to trivialize the concept of design rule. Applying this to software, it
> would mean that you go from a non-modular to a modular design simply by
> proliferating interfaces, with the sole purpose of "decoupling" every pair
> of interacting components.
>
>
> The misconception here is that our paper advocates indiscriminate
> decoupling
> of
> design decisions. That is not true. We very clearly state criteria for
> decomposing
> design into modules. At a technical level, one does this by using a
> generalized
> information hiding approach in which decisions are decoupled in a
> principled
> way
> for a variety of reasons, e.g., for parallelism in design, abstraction
> from
> complexity,
> and ease of evolution. At a business level, one does this in part driven
> by
> the goal
> of increasing the net (financial) options value of a design -- (net of the
> direct and
> opportunity costs of modularity). A cursory reading of the paper will make
> these
> points clear, and the the underlying theories and literature are
> adequately
> cited.
>
>
>
> While we can do that, those interfaces / design
> rules / decoupling are an illusion, they serve no real purpose, because
> some
> implementation dependencies are an inherent part of the problem
> formulation.
>
> There are many purposes for modularization, not just the ADT-ing purpose,
> which is what this definition seems to imply.
>
>
> The misconception here is that our notion of design rules is equivalent to
> the
> imposition of an abstract data type interface. That is not true. In fact,
> the main
> focus of the paper is on a new and very non-ADT-like concept of interface
> and
> of modularity for AOP, which in later work (see Griswold et al., IEEE
> Software,
> January/February 2006) we called the crosscut programming interface or
> XPI.
> The power core example should also make clear that design rules in our
> view
> are not equivalent in our conception to ADT-based API's. In the power cord
> case,
> the rules stipulate power levels, physical form factors, and probably
> other
> key
> properties, such as corrosion resistance under electrical current at the
> contact
> points.
>
>
>
>
> In the case of my laptop, it's
> very convenient to dettach the power cord and the battery from the main
> body
> when I travel, even if they only work for my laptop and no other laptop in
> the world. The battery-as-module is particularly convenient, as its
> performance degrades over time; it's good to be able to replace it with
> another one of exactly the same type, rather than having to buy a new
> laptop
> when the battery dies.
>
>
> The misconception here is that modularity in design and modularity in use
> are the
> same. That is not true. It's possible to have neither, either or both. A
> completely
> coupled design task could produce an artifact that is modular in use. A
> modular
> design task could produce an artifact that is completely integral in use.
> Etc. Of
> course in practice there is often a close alignment between the modular
> structure
> of the design and design task and of the artfact-in-use (as in the PC
> industry, in
> the audiophile industry, etc).
>
>
>
> In the computer industry, non-ADT-ing modularizations work to the
> financial
> advantage of market leaders... "Buy a complete modular system where some
> modules may break; you can get a replacement from us only, at $50!"
> Standardizing the technology of power cords and batteries -- technically
> simple -- would disrupt the market.
>
> Establishing design rules in a modular design has effects which you may or
> may not want. But that doesn't mean that a system isn't modular until all
> of
>
> its components depend only on design rules.
>
>
> The misconception here is that that is what we said :-) That's not true.
> What
> we said is the following: "We say that a design or a part of a design is
> modular
> if its elements do not depend on each other (although they may depend on
> external design rules that serve to decouple them)." We stand by this
> definition.
>
>
> Best regards,
> Kevin Sullivan
> University of Virginia
>
>
>
> I would claim that the whole art
> of modular design is in deciding what is *and what isn't* a design rule.
> The
>
> proliferation of trivial design rules can have a negative effect on the
> value of the design.
>
> -Crista
>
> PS. ADT = Abstract Data Type, roughly, an interface that can have many
> implementations.
>
>
> __________________________________________________
> AOSD Discuss mailing list - discuss at aosd.net
> To unsubscribe go to http://aosd.net
>
> Check out the AOSD.net Wiki: http://aosd.net/wiki
>
>
>
>
>
> --
> Kevin Sullivan
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://aosd.net/pipermail/discuss_aosd.net/attachments/20060405/779d4844/attachment.htm
>
> ------------------------------
>
> __________________________________________________
> AOSD Discuss mailing list - discuss at aosd.net
> To unsubscribe go to http://aosd.net
>
> Check out the AOSD.net Wiki: http://aosd.net/wiki
>
>
>
> End of discuss Digest, Vol 31, Issue 2
> **************************************
More information about the discuss
mailing list