[rules-users] change "assert" to "insert"+ other changes

Mark Proctor mproctor at codehaus.org
Tue Jun 12 18:26:19 EDT 2007


Only modified for this rule? Not entirely sure what you mean, what is 
wrong with a return value constraint?

We have no special date constructs beyond the standard date comparators.

Mark
Michael Rhoden wrote:
> I have a question related to this. Is there a way within a rule that 
> you can add 30 days to a date...
>  
> //mydate within last 30 days
> mydate + 30 > getdate()
> then dosomething()
>  
> I would only want mydate modified for this rule only not re-asserted 
> on the stack with a new date. Also if someone could point me in the 
> direction of some good info on dealing with dates in rules, love to 
> see more examples.
>  
> ----------------------------------------------------------------------------------------------- 
>
> -MVEL has sugar to do: modify ( person ) { age += 1, location = 
> "london" }, what actually happens here is it first calls modifyRetract 
> then applies the setters and then calles modifyAssert.
> ----------------------------------------------------------------------------------------------- 
>
>  
> Thanks,
> -Michael
>  
>
>  
>  
>  
>
> ------------------------------------------------------------------------
>    *From:* rules-users-bounces at lists.jboss.org 
> [mailto:rules-users-bounces at lists.jboss.org] *On Behalf Of *Mark Proctor
> *Sent:* Tuesday, June 12, 2007 3:39 PM
> *To:* Rules Dev List
> *Cc:* Rules Users List
> *Subject:* [rules-users] change "assert" to "insert"+ other changes
>
> Ok, I'm now doing these changes.
>
>
> Mark Proctor wrote:
>> I've had no further feedback on this, so I'm going to make this 
>> change as part of the next milestone release (this week) - these 
>> changes are considerable.
>>
>> assert will change to insert
>> -avoid the constant keyword collision with "assert", most languages 
>> are seem to support this now
>> -will change in both the drl and working memory api
>>
>> modify to become update
>> -instead of workingMemory.modify(FactHandle, Object) it will be 
>> workingMemory.update(FactHandle, Object), will change modify to 
>> update in drl.
>> -this method is now only used for ShadowFact objects, it's  a method 
>> to let the engine know that an external object has been updated and 
>> to update it's internal cache. and reprocess.
>> -avoid keyword collision in MVEL which has nice "modify" sugar now
>>
>> insertObject, retractObject and updateObject to beome insert, retract 
>> and update
>> -the Object part seems superflous, might as well remove it, 
>> especially as we start to support none Object fact types
>> -drl and working memory api will now use the same method names.
>>
>> added new WorkingMemory modifyRetract and modifyAssert methods
>> -allows for non shadow fact objects.
>> -When not using shadow facts (although will ofcourse work with shadow 
>> facts) you cannot call 'update', or what use to be called 'modify', 
>> because we need to know the "old" value of fields so we can retract 
>> the from the workign memory. The only safe way is to first retract 
>> the object and then assert it. However with the existing api this 
>> adds extra work and results in new fact handle. modifyRetract and 
>> modifyAssert can now be used together to "simulate" a modify on a 
>> none shadow fact object in two parts. First call modifyRetract, then 
>> change your field values, then call modifyAssert.
>> -MVEL has sugar to do: modify ( person ) { age += 1, location = 
>> "london" }, what actually happens here is it first calls 
>> modifyRetract then applies the setters and then calles modifyAssert.
>>
>> Mark
>>
>> Greg Barton wrote:
>>> I think it's a good idea, so ya, change to "insert"
>>>
>>> GreG
>>>
>>> --- Mark Proctor <mproctor at codehaus.org> wrote:
>>>
>>>   
>>>       
>>>> We have been getting querries with regards to jdk
>>>> assert collision and 
>>>> jboss rules assert, for this reason we are thinking
>>>> of changing it to 
>>>> insert for 4.0. Further to that its causing language
>>>> integrations issues 
>>>> for us as we expand pluggeable dialects. For this
>>>> reason we are thinking 
>>>> of chaning assert to insert, this would be an api
>>>> change and a language 
>>>> level change. I'd thought I'd throw this out to the
>>>> community before we 
>>>> do it. This of course breaks backwards
>>>> compatability.
>>>>
>>>> Mark
>>>> _______________________________________________
>>>> rules-dev mailing list
>>>> rules-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>
>>>>     
>>>>         
>>>
>>>
>>>
>>>        
>>> ____________________________________________________________________________________Get the free Yahoo! toolbar and rest assured with the added security of spyware protection.
>>> http://new.toolbar.yahoo.com/toolbar/features/norton/index.php
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>>   
>>>       
>>
>> ------------------------------------------------------------------------
>>   
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>   
>>     
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20070612/bf7186be/attachment.html 


More information about the rules-users mailing list