[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]