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

Re: AOP in Eiffel

Expand Messages
  • 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 1 of 9 , May 2, 2006
      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 2 of 9 , May 3, 2006
        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 3 of 9 , May 3, 2006
          > 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 4 of 9 , May 3, 2006
            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 5 of 9 , May 12, 2006
              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.