Re: [ovirt-devel] oVirt-specific aspect languages

Personal project (Spring based, the AOP there is extremely simple to write) and mostly for metrics and instrumentation (like adding Hystrix wrapper around all service calls). So I never really needed the advanced stuff. I also know the advice pattern from my brief excursions to Emacs Lisp where it is used to extend the editor behaviour. Martin On Wed, Apr 13, 2016 at 10:58 PM, Arik Hadas <ahadas(a)redhat.com&gt; wrote: > Hi, > > Thanks for the feedback! > I commented below. > > ----- Original Message ----- >> Hi all, >> >> I agree that it was an interesting article. >> >> > However, since AspectJ is an extension to Java, most of oVirt >> > developers would need to know additional programming language >> > which puts the cost-effectiveness of this approach into question. >> >> Actually you only need to learn some very basic stuff about pointcut >> definition. The rest was pure Java for anything I ever needed (before, >> after and around cases). >> > > Well, it depends on both the base code and the crosscutting-concerns you develop the aspects for I guess. > From my experience with AspectJ, the very basic stuff there typically fits only for very simple crosscutting concerns. > For example, in the generated aspects for the languages I developed for the crosscutting concerns in oVirt I had to use more than the basic stuff (e.g. inter-type declarations). > >> DSLs are a nice thing to have, and we can start by utilizing object >> builders more :) Those are a kind of DSL too if nicely written. See >> the latest email on this list from Roman Mohr that talks about Domain >> Object Builders (or Spring Security Java configuration [2] to see a >> more complicated example of how it is used elsewhere). >> >> Martin >> >> [1] http://lists.ovirt.org/pipermail/devel/2016-April/012790.html >> [2] >> http://docs.spring.io/spring-security/site/docs/current/reference/html/jc... >> >> On Mon, Apr 11, 2016 at 4:13 PM, Vojtech Szocs <vszocs(a)redhat.com&gt; wrote: >> > Hi Arik, >> > >> > thanks for sharing this, the article is very interesting! >> > >> > " >> > However, since AspectJ is an extension to Java, most of oVirt >> > developers would need to know additional programming language >> > which puts the cost-effectiveness of this approach into question. >> > " >> > >> > I always thought that good Java developers should be familiar >> > with AOP concepts anyway. > > I think that many are familiar with the general AOP concepts but nevertheless decide not to adopt them. > Many think that AOP is useful only for simple logging and tracing or as a simplified API for byte-code manipulation (I guess that's why AspectJ is used by GWT in our build process, right?) or in its simplified form as spring-aop, because of the known drawbacks of AspectJ. > Hopefully the proposed approach would change that :) > >> > >> > That said, I really like the combo of AOP with DSL (or ASL) >> > and I agree that it can simplify handling concerns in a way >> > that is much closer to app's domain, rather than being closer >> > to its implementation (as with AOP). >> > >> > Regards, >> > Vojtech >> > >> > >> > ----- Original Message ----- >> >> From: "Arik Hadas" <ahadas(a)redhat.com&gt; >> >> To: "devel" <devel(a)ovirt.org&gt; >> >> Sent: Monday, April 11, 2016 9:02:39 AM >> >> Subject: [ovirt-devel] oVirt-specific aspect languages >> >> >> >> Hi All, >> >> >> >> Last month I participated in Modularity'16, an academic conference that >> >> focuses on advanced software modularization techniques, where I presented >> >> my >> >> work in the area of domain specific aspect languages that was evaluated on >> >> oVirt. >> >> >> >> Many have asked me to elaborate on this work, so I wrote a post that >> >> explains >> >> the idea and provides references to relevant materials that were presented >> >> in the conference, which I would like to share with you: >> >> http://ahadas.github.io/oVirt-Specifc-Aspect-Languages/ >> >> >> >> Regards, >> >> Arik >> >> _______________________________________________ >> >> Devel mailing list >> >> Devel(a)ovirt.org >> >> http://lists.ovirt.org/mailman/listinfo/devel >> >> >> > _______________________________________________ >> > Devel mailing list >> > Devel(a)ovirt.org >> > http://lists.ovirt.org/mailman/listinfo/devel >>