[rules-dev] Re: [rules-users] No globals in functions?

[David Sinclair]

Edson,
Changing the builder shouldn't be too much of a problem. If I make the
changes you suggested, how does the global actually get passed to the
method? For example if something defined a function like

void function doX(int abc) {
   ...
   global.doY(bcd);
}
and I rewrite it to be

void function doX(int abc, GlobalType global) {
   ...
}

Who is the invoker of the method?

thanks

dave



On Mon, Oct 13, 2008 at 3:24 PM, Edson Tirelli <tirelli at post.com> wrote:

>
>    Hi Dave,
>
>    Excellent!
>    I will try to explain the current situation and one possible solution,
> but you may have better ideas.
>
>    Functions in Drools are compiled as simple static methods in a generated
> java class. We use MVEL Templates to generate the code of the class and the
> static method.
>
>    Take a look at JavaFunctionBuilder.java class for the code generation
> call and at javaFunction.mvel for the code template.
>
>    Now, the problem with globals is that they are scoped to sessions, not
> rulebases, so you can not resolve them until runtime. You can not for
> instance, make them a static reference of the generated class and set it at
> rulebase compilation time.
>
>    So, my suggestion would be to:
>
> 1. at compile time, use JavaDialect.analyzeBlock() method to analyze and
> find out what are the globals that are used by the funcion method code.
>
> 2. modify the code generation to add parameters to that in the method call.
> So, if "log" is a global and if the function is declared like this:
>
> function void someFunction( String param ) {
>     // ... code ...
>     log.something(...);
>     // ... code ...
> }
>
>    you detect the use of "log" and add it as a parameter of the generated
> method:
>
> ...
> public static void someFunction( Logger log, String Param ) {
>    ...
> }
> ...
>
>    This way, at runtime we can inject the parameter into the call. You can
> look at JavaConsequenceBuilder.java and javaInvokers.mvel to see how we do
> kind-of the same thing for consequences.
>
> 3. Now the most interesting part. :)  We use an ANTLR grammar for parsing
> Java code blocks. You need to change the parser to rewrite any function call
> the user is doing in his code to inject the log parameter transparently. I
> did the very same thing for modify blocks:
>
> modify( $something ) {
>    ...
> }
>
>    It is not hard once you get the hang of it. It is a bit of "hand work"
> though. Look at the JavaConsequenceBuilder.fixModifyBlocks() for what I did.
> Also, the ANTLR Java grammar is java.g.
>
>    Let me know if you have questions or if you have a better idea, and
> welcome aboard!
>
>    Cheers,
>        Edson
>
>
>
> 2008/10/13 David Sinclair <dsinclair at chariotsolutions.com>
>
>  Hi Edson,
>>
>> My name is dave sinclair. I started using Drools in early August of this
>> year, but have a lot of experience with rules engines. I have worked
>> primarily with ArtEntrprise and some with PegaRules. I would love to help
>> with this project and thought that this may be the area to jump in on.
>>
>> I have the M2 code, and was reading it over the weekend. Mostly the core
>> and some of the compilier. If you want to point me in the right direction on
>> the global/functions I'd be happy to have a look.
>>
>> thanks
>>
>> dave
>>
>>
>> On Mon, Oct 13, 2008 at 9:59 AM, Bagwell, Allen F <afbagwe at sandia.gov>wrote:
>>
>>>  Edson,
>>>
>>> Thanks for the tip. I figured I'd need to use a workaround like this.
>>>
>>> Unfortunately I'm under a series of tight development and test deadlines
>>> all the way into early summer. Otherwise, I'd have a look. Hopefully someone
>>> else out there can assist.
>>>
>>> Thanks,
>>> -A
>>>
>>>  ------------------------------
>>> *From:* rules-users-bounces at lists.jboss.org [mailto:
>>> rules-users-bounces at lists.jboss.org] *On Behalf Of *Edson Tirelli
>>> *Sent:* Friday, October 10, 2008 5:46 AM
>>> *To:* Rules Users List
>>> *Subject:* Re: [rules-users] No globals in functions?
>>>
>>>
>>>    Allen,
>>>
>>>    There is a technical explanation behind that and we never had the time
>>> to find a way to overcome this limitation. What you can do, although not
>>> ideal, is to send the global as a parameter:
>>>
>>> funcion void foo( Logger log, String cond )
>>> {
>>> ...
>>> }
>>>
>>> rule XYZ
>>> when
>>> then
>>>     foo( log, someString );
>>> end
>>>
>>>    If you or anyone would like to help improving this, let us know and we
>>> can discuss ways into doing it.
>>>
>>>    []s
>>>    Edson
>>>
>>> 2008/10/9 Bagwell, Allen F <afbagwe at sandia.gov>
>>>
>>>>
>>>> There's probably an easy explanation for this. I was wondering about why
>>>> functions inside of rule files can't access globals?
>>>>
>>>> For example, I have a log4j logger that I pass into my rule files via a
>>>> global.  The logger should never be a part of working memory. It's just
>>>> there to capture valuable feedback.
>>>>
>>>> But I can't do this:
>>>>
>>>> global Logger log;
>>>>
>>>> function void foo(String cond)
>>>> {
>>>>    if (cond == "error")
>>>>        log.error("I saw an error");
>>>> }
>>>>
>>>> Because the compiler says that in the function it can't resolve 'log'.
>>>>
>>>> -A
>>>>
>>>> Allen F. Bagwell
>>>> e-mail:  afbagwe at sandia.gov
>>>> phone:  505/284-4517
>>>> fax:  505/ 844-7886
>>>>
>>>> There is no monument dedicated to the memory of a committee. -- Lester
>>>> J. Pourciau
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> rules-users mailing list
>>>> rules-users at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>>
>>>>
>>>
>>>
>>> --
>>>  Edson Tirelli
>>>  JBoss Drools Core Development
>>>  JBoss, a division of Red Hat @ www.jboss.com
>>>
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>>
>>
>
>
> --
>  Edson Tirelli
>  JBoss Drools Core Development
>  JBoss, a division of Red Hat @ www.jboss.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20081014/68c48a1d/attachment.html