Re: Jim Fulton : Extensible compound statements -- new exec flavor

Ty Sarna (endicor@crl.com)
3 Feb 1995 11:26:37 -0800

In article <JFULTON.95Feb3122701@disqvarsa.er.usgs.gov>,
Jim Fulton <jfulton@disqvarsa.er.usgs.GOV> wrote:
>
> But, your __leave__ function needs to know whether to commit,
> rollback, or neither. Also, if you make the user handle this in the

Well, my leave function would have needed to know only wether to commit
or rollback -- there is no third alternative in the design I was
thinking of. (Yoda'sschool of Jedi Transaction Processing: "Do
or do not do, there is no try..." :->)

That makes things a lot simpler, but you are right that it's less flexible.
I'm also not much of an expert on transaction processing, os maybe I'm
missing something here, but I don't see the need for the third case *in
my particular application*. Now if other people do, go ahead and provide
it. I'm not opposed to that, I just don't need it myself.

> except block, you are exposing details of the transaction protocol.

I was only worried at the time about hiding the implementation of one
protocol, and not about allowing different protocols to be substituted
transparently. Obviously you're thinking alot further ahead than I am.

> > Actually, how about "as"? As in "execute this code as a transaction (or
> > thread, or whatever). "as transaction: ....", "as thread:", etc. Anyone?
>
> I really don't care what keyword is used.

I don't really care a whole lot either, though something general is good.
"locking:" is bad... too specific. I'd go for either "as" or overloading
"exec". To me, "as" seems the easiest to read and the most general. It
seems a good fit for all of the uses proposed to far:

as transaction:
as thread:
as critical_section(some_obj):
as widget.callback('<Button1>'):

etc.

So... Guido? Any chance this will make it into the language?

-Ty