/--- On Tue, Aug 29, 2000 at 04:18:57PM -0400, John Porter wrote:
| > I was thinking about this same problem while reading RFC 130. It
| > seems
| > like transactions and exceptions are closely related. Should we
| > combine
| > the two?
| > try transaction {
| > ...
| > }
How would you think that? Why it is more than a simple
try {
...
}
?
| > That's a really interesting extension to exceptions -- code that
| > has
| > no side-effects unless it finishes.
You mean: all variables are "transaction-enabled"? This must be very
hard to realize, because some variables stores states of
communications with other programs, and those cannot be restored,
because the communication has done. We need some kind of rollback,
specified to variables.
| Um, I think it should only affect C<local>ized variables, since
| transactionalizing dovetails so neatly with the semantics of
| C<local>.
|
I suggested new keyword for that: "trans" (or suggested by others,
like "acid", "onsuccess", "atomic", "transactional", etc...).
Simple "local" is not enought. Think about multi-threading and
locking also...
| > BTW, how useful are transactions on
| > internal variables if we don't provide I/O transactions too?
|
| Well, *very*, I would think; but, of course, having IO xactions
| *too*
| would be good.
|
You can do it with objects, and tie interface. It needs some some
cleanings, because it is still not functional in this state (I need
some time to write a new version of the RFC), but I think this is
the future! Look at the Object interface and TIE interface in the
RFC.
Has anybody got other idea to manage transactions outside perl, and
how it can be made usable?
\---
dLux
--
== Magzar billentzuyet ruley ==
