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

Re: AOP in Eiffel

Expand Messages
  • 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 1 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 2 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 3 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 4 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.