You have caught one of my big weakness Jonathon.
even when I re-read what I wrote many times I will not catch these type
of mistakes.
and =a
an=another


Jonathon -- Improov sent the following on 11/7/2007 4:14 AM:
> BJ,
> 
> I would ask that you say your original message again too. I couldn't
> understand either.
> 
> How would running any (typo "and"?) SECAs cause problems with a (typo
> "an"?) SECA, or any SECA at all? If I understand it right (I'm sure I
> didn't), it sounds very much like "eating bread and butter is not good,
> because it would cause problems with eating bread and butter".
> 
> As for gotchas in SECAs, I don't know any. There is the possibility of
> an infinite loop, but that is due to bad programming or design. Even
> Java can have infinite loops.
> 
> As for "unintended side effects" when adding a new SECA, you can make
> sure you hunt down all references to a trigger before attaching another
> SECA to that same trigger. Usually, again, this is to prevent infinite
> loops (cyclic dependencies).
> 
> Still, it is very easy to catch SECA problems caused by cyclic
> dependencies. Fixing those problems is just a matter of knowing what we
> want to program, and programming it (expressing it) correctly with
> cyclic dependencies or other problems (eg double-triggering).
> 
> The ECA is a very powerful event-driven architecture. If we consider
> difficulty with concurrency programming a "gotcha", then anything from
> Dojo to SWT to OFBiz's ECA will have such "gotchas". In contrast,
> consider how easy it is to use strictly procedural programming
> structures, though "easy" soon becomes "tedious" instead. ECAs are not
> exactly terribly tricky concurrency stuff, though.
> 
> Jonathon
> 
> BJ Freeman wrote:
>> In programming, a gotcha is a feature of a system, a program or a
>> programming language that works in the way it is documented but is
>> counter-intuitive and almost invites mistakes because it is both
>> enticingly easy to invoke and completely unexpected and/or unreasonable
>> in its outcome.
>>
>>
>> [EMAIL PROTECTED] sent the following on 11/6/2007 10:31 PM:
>>> BJ
>>>
>>> This did not make a lot of sense, can you rephrase it?
>>>
>>> Skip
>>>
>>> -----Original Message-----
>>> From: BJ Freeman [mailto:[EMAIL PROTECTED]
>>> Sent: Tuesday, November 06, 2007 7:03 PM
>>> To: [email protected]
>>> Subject: Gotchas for SECAS's
>>>
>>>
>>> I have read in code about not running and SECAS because it would cause
>>> problems with an seca.
>>>
>>> is there a documentations of best practices on creating SECAS. Hopefully
>>> one that covers gotchas.
>>>
>>> :)
>>>
>>>
>>>
>>>
>>
>>
> 
> 
> 
> 

Reply via email to