From: <jbo...@li...> - 2006-05-24 08:39:15
|
Author: mic...@jb... Date: 2006-05-24 04:38:59 -0400 (Wed, 24 May 2006) New Revision: 4399 Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-Function.xml labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-Rule.xml Log: typos Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-Function.xml =================================================================== --- labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-Function.xml 2006-05-24 07:13:25 UTC (rev 4398) +++ labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-Function.xml 2006-05-24 08:38:59 UTC (rev 4399) @@ -27,11 +27,11 @@ (perhaps with only differing parameters for each rule - for example the contents of an email message).</para> - <para>A typica function declaration looks like:</para> + <para>A typical function declaration looks like:</para> <para>function String calcSomething(String arg) {</para> - <para> return "hola !";</para> + <para>return "hola !";</para> <para>}</para> @@ -40,7 +40,7 @@ you don't have to have parameters if they are not needed). Return type is just like a normal method. To call the function from within a rule (in a consequence, or perhaps an eval, simply use the function name, and toss in - the parameters - just like a method call). </para> + the parameters - just like a method call).</para> <para>An alternative to a function, could be to use a static method in a helper class: Foo.doSomething(), or perhaps pass in an instance of a helper Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-Rule.xml =================================================================== --- labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-Rule.xml 2006-05-24 07:13:25 UTC (rev 4398) +++ labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Language/Section-Rule.xml 2006-05-24 08:38:59 UTC (rev 4399) @@ -894,20 +894,21 @@ <title>A note on autoboxing and primitive types</title> <para>Java 5 supports autoboxing and unboxing between primitives of - appropraite types. This makes for very convenience and easier to read - code. However, as drools runs in J2SE 1.4 as well, we can't rely on this. - Thus we have to autobox at times. Fields that are referred to are - autoboxed in the corresponding object type automatically (if they are - already an object, then there is no change). However, it is important to - note that they are not "unboxed" automatically. Thus if you bind to a - field that is an "int" in your object model, it will behave like an Object - in the rule (ie predicates, return value constraints and the RHS).</para> + appropriate types. This makes for very convenient and easy to read code. + However, as drools runs in J2SE 1.4 as well, we can't rely on this. Thus + we have to autobox at times. Fields that are referred to are autoboxed in + the corresponding object type automatically (if they are already an + object, then there is no change). However, it is important to note that + they are not "unboxed" automatically. Thus if you bind to a field that is + an "int" in your object model, it will behave like an Object in the rule + (ie predicates, return value constraints and the RHS).</para> <para>As a general rule, if possible, make your fields object types (at least until java 5), or at least think of your fields as object types even if they are not to start with). Another special note, is that for return value constraints, the return value snippet of code must return an Object (not a primitive). Now, I bet you can't wait for Java 5 to be the minimum - !</para> + ! The fact that not quite *everything* in java is an object causes + headaches like this (keep those tablets handy).</para> </section> </section> \ No newline at end of file |