OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsbpel] Issue 36 - Multiple instances of event handler


Gulp...

I'm with Maciej 100% on believing that parallel event handling is necessary
(at least, I believe it has to be supported in the syntax, even if any
particular implementation chooses to serialize everything).

I think I just misunderstood the rest of this on first reading - I'm not
sure Maciej and I mean the same thing by functional programming here? To me,
'functional programming' basically just means no explicitly assignable
variables, and - as a (not necessarily obvious) consequence - supports
static verification.  

If we're really after static verification, we really ought to be a
functional language. But we can't be, because of that damned assignment
operator (which I'm not arguing against, BTW). So the next question there
would be "can we precisely specify the limits of static verification (in at
least a programmer-friendly way)?".

But if Maciej's saying let's formalize parameters as ALWAYS being
pass-by-value (as pass-by-reference is always going to cause problems if we
DO allow parallel event - or activity, for that matter - handling), then I
agree again.

I just didn't quite see where forward referencing came into this (but then
I'm still trying to claw back 8 hours of jetlag). Does forward referencing
become an issue with SAX-like, as opposed to DOM-like, parsing?

Steve B

-----Original Message-----
From: Maciej Szefler [mailto:mbs@fivesight.com] 
Sent: 22 September 2003 15:12
To: edwink@collaxa.com; Francisco Curbera
Cc: wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue 36 - Multiple instances of event handler


I think you guys are trying to hard to map this into functional programming
style. In the pass-by-value world, a functional argument merely exposes a
variable declared inside the function scope to the calling scope (so it can
be initialized by the caller); typing the argument in the function
decleration is a notiational convenience for the programmer so that he does
not have to declare the variables twice (ala old K&R style C declerations).


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]