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] 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]