<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
    <title></title>
  </head>
  <body text="#000000" bgcolor="#ffffff">
    Hi Mario,<br>
    <br>
    Here are a few suggestions<br>
    <br>
    1) Fail fast in this case:<br>
    <blockquote type="cite"> this annotation has no effect if the
      corresponding pattern's type hasn't been annotated with
      @PropSpecific</blockquote>
    Fail Fast with an exception like this:<br>
      throw new IllegalStateException("The factClass (" + factClass + ")
    has a property (" + property + ") that has a @Modifies annotation,
    but the class isn't annotated with @PropSpecific.");<br>
    If for a later version, we receive user input that there is actually
    a good case where @Modifies exists without @PropSpecific, we can
    always allow it (vica versa is not possible).<br>
    <br>
    2) @Modifies( "firstName, lastName" ) should not put the comma (,)
    inside the quotes. Go for:<br>
      @Modifies( "firstName", "lastName" )<br>
      or @ModifiesCombination( @Modifies("firstName"),
    @Modifies("lastName") )<br>
    The last way might look a bit strange, but it's a common practice,
    for example in JPA-hibernate:<br>
     
<a class="moz-txt-link-freetext" href="http://docs.jboss.org/hibernate/core/4.0/javadocs/org/hibernate/annotations/ColumnTransformers.html">http://docs.jboss.org/hibernate/core/4.0/javadocs/org/hibernate/annotations/ColumnTransformers.html</a><br>
     
<a class="moz-txt-link-freetext" href="http://docs.jboss.org/hibernate/core/4.0/javadocs/org/hibernate/annotations/ColumnTransformer.html">http://docs.jboss.org/hibernate/core/4.0/javadocs/org/hibernate/annotations/ColumnTransformer.html</a><br>
    That last way won't break when there are additional properties on
    the @Modifies annotations (while the other approaches will):<br>
      
    @ModifiesCombination( @Modifies("firstName", whenImplementsInterface
    = FirstNameable.class), @Modifies("lastName",
    whenImplementsInterface = LastNameable.class) )<br>
    <br>
    3) What's the point of doing a @PropSpecific on a field instead of a
    class?<br>
    <blockquote type="cite">declare Person<br>
          @propSpecific<br>
          firstName : String</blockquote>
    <br>
    4) I also believe we should stick to Java naming conventions [1] as
    close as possible because the main target audience to start using
    our drools jars is the java programmers audience.<br>
    The stranger our stuff looks to them, the more likely they 'll try
    to write "a simple solution" themselves instead of using our
    "complex" framework.<br>
    4a) Like Edson says: start with a capital like all other
    annotations.
    <blockquote type="cite">
      <div>* I think we should keep the property names consistent
        between the java and the declare element, so I suggest you use
        uppercase for both (@PropSpecific). </div>
    </blockquote>
    4b) The naming conventions also state not to abbreviate to fast, so
    I 'd prefer @PropertySpecific over @PropSpecific<br>
    <br>
    <br>
    [1] Oracle's Java coding conventions, which are the base for JBoss's
    coding conventions:<br>
    <a class="moz-txt-link-freetext" href="http://www.oracle.com/technetwork/java/codeconv-138413.html">http://www.oracle.com/technetwork/java/codeconv-138413.html</a><br>
    <br>
    Op 17-01-12 20:20, Mario Fusco schreef:
    <blockquote
cite="mid:CAPYjU_kuD5RneJvJS5qriZcqR73yVrHvxg2Ah0w+TYtX6xCraA@mail.gmail.com"
      type="cite">Hi all,<br>
      <br>
      just a quick recap of what I did until now to check if we are all
      on the same page and also agree with the naming convention I used.<br>
      <br>
      The property specific feature is off by default in order to make
      the behavior of the rule engine backward compatible with the
      former releases. If you want to activate it on a specific bean you
      have to annotate it with @propSpecific. This annotation works both
      on drl type declarations:<br>
      <br>
      declare Person<br>
          @propSpecific<br>
          firstName : String<br>
          lastName : String<br>
      end<br>
      <br>
      and on Java classes:<br>
      <br>
      @PropSpecific<br>
      public static class Person {<br>
          private String firstName;<br>
          private String lastName;<br>
      }<br>
      <br>
      Moreover on Java classes you can also annotate any method to say
      that its invocation actually modifies other properties. For
      instance in the former Person class you could have a method like:<br>
      <br>
      @Modifies( "firstName, lastName" )<br>
      public void setName(String name) {<br>
          String[] names = name.split("\\s");<br>
          this.firstName = names[0];<br>
          this.lastName = names[1];<br>
      }<br>
      <br>
      That means that if a rule has a RHS like the following:<br>
      <br>
      modify($person) { setName("Mario Fusco") }<br>
      <br>
      it will correctly recognize that both the firstName and lastName
      have been modified and act accordingly. Of course the @Modifies
      annotation on a method has no effect if the declaring class isn't 
      annotated with @PropSpecific. <br>
      <br>
      The third annotation I have introduced is on patterns and allows
      you to modify the inferred set of properties "listened" by it. So,
      for example, you can annotate a pattern in the LHS of a rule like:<br>
      <br>
      Person( firstName == $expectedFirstName ) @watch( lastName ) //
      --&gt; listens for changes on both firstName (inferred) and
      lastName<br>
      Person( firstName == $expectedFirstName ) @watch( * ) // --&gt;
      listens for all the properties of the Person bean<br>
      Person( firstName == $expectedFirstName ) @watch( lastName,
      !firstName ) // --&gt; listens for changes on lastName and
      explicitly exclude firstName<br>
      Person( firstName == $expectedFirstName ) @watch( *, !age ) //
      --&gt; listens for changes on all the properties except the age
      one<br>
      <br>
      Once again this annotation has no effect if the corresponding
      pattern's type hasn't been annotated with @PropSpecific.<br>
      <br>
      I've almost finished with the development of this feature (at the
      moment I am missing the compile-time check of the properties named
      in the @watch annotation together with some more exhaustive
      tests), so if you think that I misunderstood something or there is
      room for any improvement (or you just don't like the annotation's
      names I chose) please let me know as soon as possible.<br>
      <br>
      Mario<br>
      <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
rules-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
With kind regards,
Geoffrey De Smet</pre>
  </body>
</html>