Loading ...
Sorry, an error occurred while loading the content.

AOP in Eiffel

Expand Messages
  • Marco Piccioni
    Hello, I think that in the Java world AOP has brought some benefits, especially with the so-called crosscutting concerns (logging being a typical example).
    Message 1 of 9 , May 1, 2006
    • 0 Attachment
      Hello,
      I think that in the Java world AOP has brought some benefits, especially with the so-called crosscutting concerns (logging being a typical example).
      What about AOP in the Eiffel world? Are there any plans about introducing it in Eiffel? Does anyone want to share his thoughts about that?

      Marco Piccioni

      [Non-text portions of this message have been removed]
    • Bernd Schoeller
      ... Without speaking for others, you might see that AOP is seen very critical within the Eiffel community. The major reason is that there is very little common
      Message 2 of 9 , May 1, 2006
      • 0 Attachment
        On Mon, May 01, 2006 at 07:31:14PM +0200, Marco Piccioni wrote:
        >
        >
        > Hello,

        > I think that in the Java world AOP has brought some benefits,
        > especially with the so-called crosscutting concerns (logging being a
        > typical example). What about AOP in the Eiffel world? Are there any
        > plans about introducing it in Eiffel? Does anyone want to share his
        > thoughts about that?

        Without speaking for others, you might see that AOP is seen very
        critical within the Eiffel community. The major reason is that there
        is very little common understanding what AOP is and how it integrates
        into software development.

        There are - perhaps - very few applications for these things that are
        called "Aspects". The two that pop up in any AOP discussion is
        debugging and logging. But a solution to a few very specific problems
        does not qualify to base a whole philosophy of software development on
        it (as the term "aspect oriented programming" implies). Specially for
        "functional decomposition" - one major dimension of system design -
        AOP does not offer any feasible solution.

        More specific to Eiffel, AOP is a major violation to the "Single
        Document Principle". This principle is at the heart of the DbC
        philosophy.

        Regards,
        Bernd
      • Marco Piccioni
        ... From: Bernd Schoeller To: Sent: Monday, May 01, 2006 8:09 PM Subject: Re:
        Message 3 of 9 , May 1, 2006
        • 0 Attachment
          ----- Original Message -----
          From: "Bernd Schoeller" <bernd.schoeller@...>
          To: <eiffel_software@yahoogroups.com>
          Sent: Monday, May 01, 2006 8:09 PM
          Subject: Re: [eiffel_software] AOP in Eiffel


          >
          > Without speaking for others, you might see that AOP is seen very
          > critical within the Eiffel community. The major reason is that there
          > is very little common understanding what AOP is and how it integrates
          > into software development.
          > There are - perhaps - very few applications for these things that are
          > called "Aspects". The two that pop up in any AOP discussion is
          > debugging and logging.

          This seems too limitative to me. I have seen useful applications of AOP in
          transaction management, in caching, in monitoring application performance
          for example.

          >But a solution to a few very specific problems
          > does not qualify to base a whole philosophy of software development on
          > it (as the term "aspect oriented programming" implies).

          Agreed, in general, on the excessive emphasis on the term, but I think that
          nobody among the AOP guys mean to base a whole philosophy of software
          development on it. If some AOP enthusiasts ever do, that should be regarded
          as a terrible mistake, of course.

          > Specially for
          > "functional decomposition" - one major dimension of system design -
          > AOP does not offer any feasible solution.
          >
          I think that's not AOP intention. I see it as a way to add flexibility to
          code, and as we already know, flexibility always comes at a price (see
          after)

          > More specific to Eiffel, AOP is a major violation to the "Single
          > Document Principle". This principle is at the heart of the DbC
          > philosophy.

          The main idea of AOP is to separate recurring functionalities (aspects) from
          code that is not semantically related to them. To a certain extent AOP tries
          to achieve flexibility through a sort of encapsulation, targeting aspects
          instead of types.
          I think that in principle we should evaluate pros and cons of the approach.
          After all, object oriented way of thinking has broken more than one
          "principle" in the past! I list what I can observe, at least in java
          applications I have seen:
          1) Application code tends to be cleaner, more focused on business logic out
          handling transactions)
          2) Aspects code is placed somewhere else, but that is true for application
          configuration files too, and I think no one think that they are not useful!
          The main point here is: do we want transaction management be handled like
          business logic or not? That is probably a matter of opinions

          >
          >
          >
          >
          >
          >
        • Marco Piccioni
          Sorry Bernd, I have misclicked on the send button before finishing a last phrase. Thank you for your patience 8) Marco Original Message ----- From: Bernd
          Message 4 of 9 , May 1, 2006
          • 0 Attachment
            Sorry Bernd,
            I have misclicked on the "send" button before finishing a last phrase.
            Thank you for your patience 8)
            Marco

            Original Message -----
            From: "Bernd Schoeller" <bernd.schoeller@...>
            To: <eiffel_software@yahoogroups.com>
            Sent: Monday, May 01, 2006 8:09 PM
            Subject: Re: [eiffel_software] AOP in Eiffel


            >
            > Without speaking for others, you might see that AOP is seen very
            > critical within the Eiffel community. The major reason is that there
            > is very little common understanding what AOP is and how it integrates
            > into software development.
            > There are - perhaps - very few applications for these things that are
            > called "Aspects". The two that pop up in any AOP discussion is
            > debugging and logging.

            This seems too limitative to me. I have seen useful applications of AOP in
            transaction management, in caching, in monitoring application performance
            for example.

            >But a solution to a few very specific problems
            > does not qualify to base a whole philosophy of software development on
            > it (as the term "aspect oriented programming" implies).

            Agreed, in general, on the excessive emphasis on the term, but I think that
            nobody among the AOP guys mean to base a whole philosophy of software
            development on it. If some AOP enthusiasts ever do, that should be regarded
            as a terrible mistake, of course.

            > Specially for
            > "functional decomposition" - one major dimension of system design -
            > AOP does not offer any feasible solution.
            >
            I think that's not AOP intention. I see it as a way to add flexibility to
            code, and as we already know, flexibility always comes at a price (see
            after)

            > More specific to Eiffel, AOP is a major violation to the "Single
            > Document Principle". This principle is at the heart of the DbC
            > philosophy.

            The main idea of AOP is to separate recurring functionalities (aspects) from
            code that is not semantically related to them. To a certain extent AOP tries
            to achieve flexibility through a sort of encapsulation, targeting aspects
            instead of types.
            I think that in principle we should evaluate pros and cons of the approach.
            After all, object oriented way of thinking has broken more than one
            "principle" in the past! I list what I can observe, at least in java
            applications I have seen:
            1) Application code tends to be cleaner, more focused on business logic
            (think about
            handling transactions in every method)
            2) Aspects code is placed somewhere else, but that is true for application
            configuration files too, and I think no one think that they are not useful!
            The main point here is: do we want transaction management be handled like
            business logic or not? That is probably a matter of opinions

            Thanks for having shared your thoughts, Bernd!
            Best Regards
            Marco
            >
            >
            >
            >
            >
            >
          • Greg C
            Regarding AOP and Eiffel: I looked into AOP some time ago, read up on it, attended a presentation by the author of a book about it, talked to several people
            Message 5 of 9 , May 2, 2006
            • 0 Attachment
              Regarding AOP and Eiffel:

              I looked into AOP some time ago, read up on it, attended a presentation by the
              author of a book about it, talked to several people about it (including a
              doctoral candidate in computer design that was working on metaprogramming and
              Eiffel) and came to the following conclusions:

              AOP is a limited form of metaprogramming best suited to people who "don't get"
              metaprogramming. It's quite reasonable to apply metaprogramming to Eiffel, and
              we would be better off to focus on the more powerful concept.

              The fact that the inventors of AOP received a patent on the technology left me
              with a bad taste. See http://www.pmg.lcs.mit.edu/~chandra/publications/aop.html
              The amount of prior art on these techniques dates back to at least the 1980s
              and probably to the 1970s.

              From a distance, the hype surrounding AOP reminds me of the hype around UML. It
              seems better designed to sell books, tools and consulting services, rather than
              actually advancing the state of the art (especially considering all the prior
              art).

              I think it would be nice if we had better facilities for metaprogramming with
              Eiffel, and simply did not worry about AOP. There are interesting things we
              could accomplish by thinking of Eiffel source code as data, amenable to
              manipulation by other programs. And the relatively simple syntax of Eiffel
              lends itself to this.

              For example, we might want to add contracts to all features that receive a
              string, to guarantee the string is not void. Or this could be generalized to
              all reference types in an argument list.

              Or we could specify that all the classes in a given cluster only have
              dependencies on a known set of clusters. This would help support library
              maintenance and reduce code bloat when a new class unintentionally pulls in a
              new cluster.

              Regards,

              Greg C

              __________________________________________________
              Do You Yahoo!?
              Tired of spam? Yahoo! Mail has the best spam protection around
              http://mail.yahoo.com
            • John_Duh
              The things you want to solve with metaprogramming, I think might be interesting to be able to solve. But I also think that some sort of preprocessor (if that s
              Message 6 of 9 , May 3, 2006
              • 0 Attachment
                The things you want to solve with metaprogramming, I think might be
                interesting to be able to solve. But I also think that some sort of
                preprocessor (if that's what you were thinking of) - with its own
                syntax, distorting your eiffel code - is a bit an opportunistic way to
                try this, and not fitting in the eiffel philosophy.

                What I think would be a better solution, is using introspection in
                combination with invariant; like "for all routines in this class
                require that for all their parameters it holds that if they're
                references, then they don't refer to Void". Though this would be
                eiffel code (/= preprocessor language), I don't like specifying in
                'invariant' what the class should look like, rather than the object.

                But maybe there's even a nicer solution. You said: "There are
                interesting things we could accomplish by thinking of Eiffel source
                code as data". I would say: "... by thinking of Eiffel routines as
                objects" (like with agents). What could we do with routines of types
                derived from FUNCTION (\- e.g. SAFE_FUNCTION with a predefined require
                clause? Something like:

                ...
                feature
                x: MY_TYPE is
                type
                SAFE_FUNCTION
                do
                ...
                end
                ...

                I would like to hear your reactions on that.

                Regards,

                John


                --- In eiffel_software@yahoogroups.com, Greg C <gmc444@...> wrote:
                >
                > Regarding AOP and Eiffel:
                >
                > I looked into AOP some time ago, read up on it, attended a
                presentation by the
                > author of a book about it, talked to several people about it
                (including a
                > doctoral candidate in computer design that was working on
                metaprogramming and
                > Eiffel) and came to the following conclusions:
                >
                > AOP is a limited form of metaprogramming best suited to people who
                "don't get"
                > metaprogramming. It's quite reasonable to apply metaprogramming to
                Eiffel, and
                > we would be better off to focus on the more powerful concept.
                >
                > The fact that the inventors of AOP received a patent on the
                technology left me
                > with a bad taste. See http://www.pmg.lcs.mit.edu/~chandra/
                publications/aop.html
                > The amount of prior art on these techniques dates back to at least
                the 1980s
                > and probably to the 1970s.
                >
                > From a distance, the hype surrounding AOP reminds me of the hype
                around UML. It
                > seems better designed to sell books, tools and consulting services,
                rather than
                > actually advancing the state of the art (especially considering all
                the prior
                > art).
                >
                > I think it would be nice if we had better facilities for
                metaprogramming with
                > Eiffel, and simply did not worry about AOP. There are interesting
                things we
                > could accomplish by thinking of Eiffel source code as data, amenable
                to
                > manipulation by other programs. And the relatively simple syntax of
                Eiffel
                > lends itself to this.
                >
                > For example, we might want to add contracts to all features that
                receive a
                > string, to guarantee the string is not void. Or this could be
                generalized to
                > all reference types in an argument list.
                >
                > Or we could specify that all the classes in a given cluster only
                have
                > dependencies on a known set of clusters. This would help support
                library
                > maintenance and reduce code bloat when a new class unintentionally
                pulls in a
                > new cluster.
                >
                > Regards,
                >
                > Greg C
                >
                > __________________________________________________
                > Do You Yahoo!?
                > Tired of spam? Yahoo! Mail has the best spam protection around
                > http://mail.yahoo.com
                >
              • Greg C
                ... [...] ... (sound of hand thumping forehead) Yes, of course it woudl be great if Eiffel treated its own internals as objects that could be manipulated
                Message 7 of 9 , May 3, 2006
                • 0 Attachment
                  > From: "John_Duh" john_duh@...
                  [...]
                  > But maybe there's even a nicer solution. You said: "There are
                  > interesting things we could accomplish by thinking of Eiffel source
                  > code as data". I would say: "... by thinking of Eiffel routines as
                  > objects" (like with agents). What could we do with routines of types
                  > derived from FUNCTION (\- e.g. SAFE_FUNCTION with a predefined require
                  > clause? Something like: [example deleted]

                  (sound of hand thumping forehead) Yes, of course it woudl be great if Eiffel
                  treated its own internals as objects that could be manipulated
                  programmatically.

                  In your example, why couldn't we query FUNCTION for its list of arguments and
                  types, and then for each reference type, add require clauses stating that they
                  are non-void? Same thing with FUNCTION's return value; we could add an ensure
                  clause stating Void is not returned. Perhaps the code would look something like
                  this:

                  feature make_function_safe(a_func: FUNCTION[ANY, TUPLE[], ANY]) is
                  do
                  a_func.arguments.do_all( agent add_requirement(a_func.requirements, ?))
                  end

                  add_requirement(a_reqs: REQUIRE_CLAUSE_LIST; a_arg: ARGUMENT) is
                  -- only put clauses on args that aren't already covered
                  -- and are references
                  do
                  if not a_reqs.references(a_arg) and then is_reference(a_arg) then
                  a_reqs.append(a_arg.name + "_not_void: " +
                  ar_arg.name + " /= Void")
                  end
                  end

                  Someone already pointed out that if we allowed this in the language, the notion
                  of whole systems analysis might have to be tossed out of the window. As much as
                  I hate to say it, it may be worth dumping WSA for this and for other reasons. I
                  don't think Whole Systems Analyis has lived up to its promise. Certainly I've
                  not seen the performance and efficiency benefits I'd expect, and approaches for
                  generating dynamic code have come a long ways. Some Lisp interpretors are
                  supposed to produce very efficient code. WSA has also stood in the way of
                  creating libraries and their inverse -- frameworks that can accept binary
                  plugins.

                  Regards,

                  Greg C











                  __________________________________________________
                  Do You Yahoo!?
                  Tired of spam? Yahoo! Mail has the best spam protection around
                  http://mail.yahoo.com
                • Raphael Simon [ES]
                  ... Just a quick note to say that system wide analysis can still be performed on dynamically executed code. It just means that it has to be done upon loading
                  Message 8 of 9 , May 3, 2006
                  • 0 Attachment
                    Greg C wrote:
                    > Someone already pointed out that if we allowed this in the language,
                    > the notion of whole systems analysis might have to be tossed out of
                    > the window.

                    Just a quick note to say that system wide analysis can still be
                    performed on dynamically executed code. It just means that it has to be
                    done upon loading of the code (so you'd have to reproduce some of what
                    the compiler does dynamically). The problem becomes performance, but
                    then again - in general - dynamically executed code comes at a price.

                    --
                    Raphaël.
                  • John_Duh
                    I just encountered something that might interest you (an eiffel preprocessor). Good luck with it. http://www.gobosoft.com/eiffel/gobo/portability/gepp.html ...
                    Message 9 of 9 , May 12, 2006
                    • 0 Attachment
                      I just encountered something that might interest you (an eiffel
                      preprocessor). Good luck with it.

                      http://www.gobosoft.com/eiffel/gobo/portability/gepp.html


                      --- In eiffel_software@yahoogroups.com, Greg C <gmc444@...> wrote:
                      > Regarding AOP and Eiffel:
                      >
                      > I looked into AOP some time ago, read up on it, attended a
                      presentation by the
                      > author of a book about it, talked to several people about it
                      (including a
                      > doctoral candidate in computer design that was working on
                      metaprogramming and
                      > Eiffel) and came to the following conclusions:
                      >
                      > AOP is a limited form of metaprogramming best suited to people who
                      "don't get"
                      > metaprogramming. It's quite reasonable to apply metaprogramming to
                      Eiffel, and
                      > we would be better off to focus on the more powerful concept.
                      >
                      > The fact that the inventors of AOP received a patent on the
                      technology left me
                      > with a bad taste. See
                      http://www.pmg.lcs.mit.edu/~chandra/publications/aop.html
                      > The amount of prior art on these techniques dates back to at least
                      the 1980s
                      > and probably to the 1970s.
                      >
                      > From a distance, the hype surrounding AOP reminds me of the hype
                      around UML. It
                      > seems better designed to sell books, tools and consulting services,
                      rather than
                      > actually advancing the state of the art (especially considering all
                      the prior
                      > art).
                      >
                      > I think it would be nice if we had better facilities for
                      metaprogramming with
                      > Eiffel, and simply did not worry about AOP. There are interesting
                      things we
                      > could accomplish by thinking of Eiffel source code as data, amenable to
                      > manipulation by other programs. And the relatively simple syntax of
                      Eiffel
                      > lends itself to this.
                      >
                      > For example, we might want to add contracts to all features that
                      receive a
                      > string, to guarantee the string is not void. Or this could be
                      generalized to
                      > all reference types in an argument list.
                      >
                      > Or we could specify that all the classes in a given cluster only have
                      > dependencies on a known set of clusters. This would help support library
                      > maintenance and reduce code bloat when a new class unintentionally
                      pulls in a
                      > new cluster.
                      >
                      > Regards,
                      >
                      > Greg C
                      >
                      > __________________________________________________
                      > Do You Yahoo!?
                      > Tired of spam? Yahoo! Mail has the best spam protection around
                      > http://mail.yahoo.com
                      >
                    Your message has been successfully submitted and would be delivered to recipients shortly.