[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Gotos Considered Harmful?
I believe that gotos are harmful because they cause linear business processes (business processes are not necessarily procedural). > -----Original Message----- > From: Assaf Arkin [mailto:arkin@intalio.com] > Sent: Wednesday, July 09, 2003 10:35 AM > To: Ron Ten-Hove > Cc: Jim Webber; wsbpel@lists.oasis-open.org > Subject: Re: [wsbpel] Gotos Considered Harmful? > > Very illuminating article. Both Jim and Ron raise a good point. > > Like any good - and some bad - ideas, goto has survived the prohibition > period due to nothing more than it usefulness. It's been resurrected, > relaballed and under new name has been the topic of discussion in this > and related groups. We can't not use it, we just fell better using it > under a different names. I'm not suggesting we resurrect goto from the > dead, just that we recognize what we're dealing with. > > As the article points out, it's all about explicit transfer or control. > The issue that Dijkstra was trying to correct was the lack of formalism > and proper controls in Fortran. Gotos and common blocks were not evil by > themselves. They just lacked the sufficient mechanism to make them > useable. The risks - mostly bugs arising from code change - outweighted > the benefits. > > We've followed Dijkstra's teaching and took those structures out of the > language only to end up with useless development tools. But being too > damn useful they resurfaced as capabilities external to the language. > And with the proper set of controls and formalisms, ended being damn > good solutions. > > Common blocks were replaced with shared data in the database. Same > concept, same problems. Yet, where Fortan lacked any formalism and > mechanisms to deal with race conditions, concurrent and serial access, > segmentation, etc, the RDBMS brought back the ability to use shared data > in a safe way. > > Gotos has resurfaced in the form of callback. Think of any decent > enterprise application, in particular one involving long running > process. Can you imagine it without the use of callbacks? Yet, what is a > callback other than a more capable means for 'explicit control transfer'? > > As I pointed out previously, using event handlers as the basis for an > example, we do have this looping capability already ingrained in the > language. It wasn't part of BPEL 1.0, but I guess the authors felt it > was useful enough to add this capability to 1.1. We can treat is as > taboo and try to ignore its existence, we can remove it from the > language (rollback to 1.0), or we tackle it heads on and build tools > that can make the most out of it. Any preferences? > > arkin > > > Ron Ten-Hove wrote: > > > I afraid we may be reasoning by anology here. Cycles in a process > > graph may "smell" like gotos to those of us steeped in the lore of > > software engineering, but to a business analyst they are a natural, > > necessary construct. They describe how real business processes work. > > > > Trying to impose "fashionable" structured software concepts on > > another domain sounds like a questionable exercise, if the objective > > is to model the business process at a high level. If this is not the > > intent, then let us by all means attempt to structure BPEL processes > > according to good software engineering practices, including being wary > > of unstructured constructs. > > > > -Ron > > > > P.S. Does anybody remember computed GOTOs in Fortran IV? If gotos are > > considered to be harmful, then the computed goto must be > > life-threatening! > > > > Jim Webber wrote: > > > >> After hearing the arguments against Gotos on today's telcon, I have to > >> (unfashionably) suggest that they're not so bad. See: > >> http://www.ppig.org/papers/12th-marshall.pdf for a short argument in > >> favour > >> of not ignoring Gotos. > >> Note it isn't BPEL-specific, but makes the general point that there > >> are some > >> places where a Goto is the right thing to use (though those > >> situations are > >> few and far between). > >> > >> Jim > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org > >> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org > >> > >> > >> > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org > > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]