Gotchas for SECAS's

[BJ Freeman]

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.

:)

[SkipDever]

BJ

This did not make a lot of sense, can you rephrase it?

Skip

-----Original Message-----
From: BJ Freeman [mailto:[hidden email]]
Sent: Tuesday, November 06, 2007 7:03 PM
To: [hidden email]
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.

:)

[BJ Freeman]

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.


skip@theDevers 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:[hidden email]]
> Sent: Tuesday, November 06, 2007 7:03 PM
> To: [hidden email]
> 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.
>
> :)
>
>
>
>

[jonwimp]

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.
>
>
> skip@theDevers 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:[hidden email]]
>> Sent: Tuesday, November 06, 2007 7:03 PM
>> To: [hidden email]
>> 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.
>>
>> :)
>>
>>
>>
>>
>
>

[BJ Freeman]

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.
>>
>>
>> skip@theDevers 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:[hidden email]]
>>> Sent: Tuesday, November 06, 2007 7:03 PM
>>> To: [hidden email]
>>> 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.
>>>
>>> :)
>>>
>>>
>>>
>>>
>>
>>
>
>
>
>

[SkipDever]

BJ

Ah, well, this "I have read in code about not running and SECAS because it
would cause
problems with an seca."  is what I was asking for clarification on.

-----Original Message-----
From: BJ Freeman [mailto:[hidden email]]
Sent: Wednesday, November 07, 2007 3:51 AM
To: [hidden email]
Subject: Re: Gotchas for SECAS's


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.


skip@theDevers 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:[hidden email]]
> Sent: Tuesday, November 06, 2007 7:03 PM
> To: [hidden email]
> 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.
>
> :)
>
>
>
>