Naming Classes That Do then Undo (was: RAII Naming)
Rob Stewart
Naming," has fragmented. Many folks were only willing to discuss
RAII (as the subject suggested, of course). I kept trying to
discuss another type of class, which I claim includes RAII. I
want to find a name for that type of class.
Let me summarize what I recall of the non-RAII-specific
discussion so far.
After much gnashing of teeth, I realized that some
definitions/explanations were in order as to precisely what I was
discussing. Below is a taxonomy of classes that I'm referring
to. I have modified this from my earlier version to -- hopefully
-- clarify it.
DU (Do, Undo)
|
SU (Set, Undo)
|
U (Undo)
Each type of class is charged with saving current state then
restoring that state in its dtor. This is implied by the "U"
(Undo) aspect. This is the essence of RAII, exemplified by
std::auto_ptr.
Some classes save the current state, set the supplied new state,
then later, in the dtor, restore the initial state. These are
the "SU" classes. An example of this type of class is one that
manages a GUI cursor. The ctor (or a mutator for two-state
initialization) accepts the new cursor to set (the new state).
The dtor restores the original cursor.
Still other classes, the "DU" classes, save the current state,
set a fixed (or well-known) new state, then later restore the
initial state. The distinction here is that "DU" classes "know"
the new state, whereas "SU" are given the new state. An example
of "DU" classes is the WaitCursor class. This class saves the
current cursor, sets the wait cursor, then later restores the
original cursor.
The differences between DU and SU is small, but important. It is
the difference between naming the class WaitCursor and
ManageCursor (or whatever).
In the other thread, folks are continuing to debate the name for
U classes. In this thread, I'd like to discuss the naming of DU
and SU classes. Some of the names suggested already are:
Jeeves (eliciting great praise and consternation)
Save And Restore/Set And Restore
Scoped State
Sentry (mentally tied to synchronization, I think)
Do And Restore
Temp (also used as a prefix for such classes)
Excursion (which few seem to like :-( )
Surround
State Manager
Transient
One question is whether DU and SU classes should have a common
name or separate names. The distinction between them is small,
so a common name is probably sufficient.
Thoughts? Diatribes? Rants? Suggestions?
--
Robert Stewart | rob-at-giage-dot-com
Software Engineer | using std::disclaimer;
Giage, Ltd. | http://www.giage.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Andrei Alexandrescu
news:38F727D1...@giage.com...
[snip, including the J word]
> Save And Restore/Set And Restore
> Scoped State
> Sentry (mentally tied to synchronization, I think)
> Do And Restore
> Temp (also used as a prefix for such classes)
> Excursion (which few seem to like :-( )
> Surround
> State Manager
> Transient
Do-Undo
Do-Undo
Do-Undo
Do-Undo is the best:
1. "Undo" is great and applies to cursors, colors, memory, you name it.
2. "Do" is vague enough so that it can cover situations when it's the user
who "does", and not the class. Besides, it's better to have a name that is
all-inclusive that being factionalist. I would call std::auto_ptr a do-undo
class, even if technically it's not. Besides, there is always a "do"
associated with auto_ptr, evenb though it's done by the user.
3. Do-Undo is terse and easy to talk about. Believe me, this *is* important.
The first think I don't like about RAII is that it's too long to be
practical and it's pray to the YAA (Yet Another Acronym) phenomenon. If
there was not this, I would have accepted RAII because it's largely known.
(Who cares it's a bit misleading? Look at Visitor. It's misleading, but I
like it because it's short and because everybody into patterns knows about
it.)
4. Do-Undo is hardly confused with other domains/idioms, as is Sentry.
5. Do-Undo is the best :o).
> One question is whether DU and SU classes should have a common
> name or separate names. The distinction between them is small,
> so a common name is probably sufficient.
"Do" means to do anything, including "Set" or even "nothing". (The empty set
is a set, huh?) "Set" does not include "Do". Let's use "Do".
Andrei-Unandrei
Ian Knowles
>The thread titled, "Resource Acquisition Is Initialization
>Naming," has fragmented. Many folks were only willing to discuss
>RAII (as the subject suggested, of course). I kept trying to
>discuss another type of class, which I claim includes RAII. I
>want to find a name for that type of class.
I had originally posted this in the other thread but as per your
suggestion I am re-posting it here:
I received a suggestion (via email from John Hickin) for the name
"Scoped" (actually he used ScopedFoo and I dropped the Foo ;).
I think this makes a good prefix (in place of my earlier "Temp" prefix
suggestion).
After playing around with it a bit I think it actually reads quite
well, consider:
ScopedResource, ScopedState, ScopedValue< bool >, ScopedLock,
ScopedTransaction, ScopedWaitCursor, ScopedWindowColorChange,
ScopedYesToAllPrompts, ScopedInterfaceBinder, etc.
As "scoped" is an adjective it follows that "Foo is a Scoped class".
Also it removes any confusion with *real* temporaries and is not
easily confused with other common words.
It may seem obvious that any C++ object *has* scoped behaviour,
however, as we seem to find it important to identify those objects
whose "scopes" determine transitory value/state changes I think this
is not a bad name.
Regards,
Ian Knowles (remove the .nospam to reply)
Francis Glassborow
<andre...@hotmail.com> writes
>"Do" means to do anything, including "Set" or even "nothing". (The empty set
>is a set, huh?) "Set" does not include "Do". Let's use "Do".
Saying a thing many times does not make it more appropriate. Indeed if
it were as obvious as you think it would only need saying once. To me a
do-undo class is one that logs actions so that they can be done, undone
and redone:)
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
nmus...@my-deja.com
passive way and classes that perform actions. I would name the second,
as you suggest Do-Undo, and the first Set-Reset.
Best regards,
Nicola Musatti
Sent via Deja.com http://www.deja.com/
Before you buy.
Francis Glassborow
<donot...@giage.com> writes
>Thoughts? Diatribes? Rants? Suggestions?
I have just finished reading an excellent book entitled 'Dust or Magic'.
One point the author makes is the penalty we pay for using metaphors.
Metaphors (such as those we see on our desktops) create expectations
that are often not met. Metaphors are intended to help us to
intuitively understand the purpose of something. Those of us who have
understood your naming question have been seeking an appropriate
metaphor as if there is some unique name out there that would
intuitively convey the right sense almost without explanation. I think
this is the wrong direction. What we need is a name that cannot
conceivably have any other meaning in the context of programming and
then provide it with the meaning we want. 'Jeeves' was violently shot
down by one contributor because the name meant nothing to him. Having no
meaning (while have a selection criterion) is exactly what we need. We
can tell others what characterises a Jeeves class and explain why we
chose the name. A metaphor carries a semantic value and unless it is an
exact match it will communicate false information.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
John B. Breckenridge
> I see a stronger distinction between classes that model state in a
> passive way and classes that perform actions. I would name the second,
> as you suggest Do-Undo, and the first Set-Reset.
I like Do-Undo, but I prefer Store-Restore to Set-Reset.
The class may just be used to remember the state of something,
and put it back in its destructor.
For example, I have a little class like this, for keeping my program
in the same directory.
class DirKeeper
{
private:
Directory d; // Platform-specific type for directory
public:
DirKeeper()
d = GetCurrentDirectory; // Platform-specific function
};
~DirKeeper() {
ChangeDirectory(d); // Platform-specific function
};
}
In my code, I'd have something like:
void foo()
{
DirKeeper dk;
// Call some function that may end up in a new directory
}
I'd say this class fits into the Set-Reset model, but it doesn't
set anything.
--
John Breckenridge
Software Development Manager
Boothroyd Dewhurst, Inc.
Gerhard Menzl
> I have just finished reading an excellent book entitled 'Dust or Magic'.
> One point the author makes is the penalty we pay for using metaphors.
> Metaphors (such as those we see on our desktops) create expectations
> that are often not met. Metaphors are intended to help us to
> intuitively understand the purpose of something. Those of us who have
> understood your naming question have been seeking an appropriate
> metaphor as if there is some unique name out there that would
> intuitively convey the right sense almost without explanation. I think
> this is the wrong direction. What we need is a name that cannot
> conceivably have any other meaning in the context of programming and
> then provide it with the meaning we want. 'Jeeves' was violently shot
> down by one contributor because the name meant nothing to him. Having no
> meaning (while have a selection criterion) is exactly what we need. We
> can tell others what characterises a Jeeves class and explain why we
> chose the name. A metaphor carries a semantic value and unless it is an
> exact match it will communicate false information.
I agree that metaphors, when taken too literally rather than with a
grain of salt, can defeat their own purpose. But your view would
prohibit the use of metaphors altogether. A metaphor is never an exact
match, for if it were, it would not be a metaphor anymore. Both everyday
and technical language are full of "inexact" metaphors. Most design
pattern names are: we know what is meant by a Facade, and nobody
(except, perhaps, certain participants of unmoderated GUI newsgroups)
will think of painting because that's what you do normally to with
facades. Consider the term "stack", which is universally understood
among software engineers (except, perhaps, stubborn German or French
programmers). Does anyone imagine the stack toppling over when it
exceeds a certain height? No, because the name has sufficiently detached
itself from its original meaning to denote a new concept. Considering
how difficult it is already to agree on a term borrowed from everyday
language, I think we will never get anywhere if we try to make up a name
that is yet untouched by meaning, which, by the way, does not hold for
Jeeves either. Jeeves is just as metaphorical as Excursion or Sentry.
It's an allegory in reverse, if you like.
That said, I find all suggestions that involve combinations of words,
such as Do And Restore or, sorry Andrei, Do-Undo awkward. I can imagine
the latter soon to be corrupted to Doobedoo, and I don't think we want
Sinatra classes. My favourites are all names that convey the idea of
cleaning up or maintaining and restoring order, such as Janitor,
Caretaker, Butler, Stewar[d|t], Sentry, or Roadie (have we had Minion?),
and I would prefer a single name for DU, SU, and U because I think the
distinction is a mere detail and a matter of subcategories. You hire (=
create) someone (= an object) for a short time (= its scope) to clean up
the mess (= restore the state of the program no matter how the scope is
left); sometimes he'll be involved in creating it (= change the state in
its constructor), and sometimes not. The idiom to convey is that a
single declaration at the beginning of a scope will make the compiler do
all (de)initialization work in the background so that the programmer can
concentrate on the primary algorithm and is not distracted by menial
work. I feel that if we place too much emphasis on diverse variants and
try to find different names for them, this main message will be lost.
Gerhard Menzl
Sam Lindley
> Naming," has fragmented. Many folks were only willing to discuss
> RAII (as the subject suggested, of course). I kept trying to
> discuss another type of class, which I claim includes RAII. I
> want to find a name for that type of class.
RAII may not be pretty, but it is well known, and does describe a useful
pattern. Unfortunately, as I'm sure has already been pointed out, this
does
not account for destruction of objects / release of resources as objects
go
out of scope. How about considering a separate term for this pattern?
What
about "Leaving Scope Is Destruction" - LSID (El Sid)?
Of course it would also be useful to be able to refer to the combined
pattern (RAIILSID :-)), as it is so fundamental to object-orientated C++
development. Its surprising how difficult it is to come up with a good
metaphor. Perhaps it would be useful to try to create a taxonomy of not
just
the 'classes' you mention, but also of other well established patterns,
and
then choose a term which fits well within that taxonomy.
The easiest way to establish a term is to have it published in a widely
read
text book - e.g. Stroustrup's 'The C++ Programming Language': RAII; GoF
'Design Patterns': Singleton, Flyweight, Visitor, etc. If you could
persuade
Bjarne Stroustrup to use Do-Undo, Jeeves or whatever, in his next
edition of
'The C++ Programming Language', then everyone would use it.
Sam Lindley
Harald Luessen
<gerhar...@sea.ericsson.se> wrote:
>I agree that metaphors, when taken too literally rather than with a
>grain of salt, can defeat their own purpose. But your view would
>prohibit the use of metaphors altogether. A metaphor is never an exact
>match, for if it were, it would not be a metaphor anymore. Both everyday
>and technical language are full of "inexact" metaphors. Most design
>pattern names are: we know what is meant by a Facade, and nobody
>(except, perhaps, certain participants of unmoderated GUI newsgroups)
>will think of painting because that's what you do normally to with
>facades. Consider the term "stack", which is universally understood
>among software engineers (except, perhaps, stubborn German or French
>programmers). Does anyone imagine the stack toppling over when it
>exceeds a certain height? No, because the name has sufficiently detached
>itself from its original meaning to denote a new concept.
The not so stubborn German programmers use German in real life and
write (parts of) their programs in English. 'Stack' is a word with
a very special meaning. It's a data structure. Things that are put on
top of each other are called 'Stapel' in German. This way the danger
of misleading metaphors is reduced. Of course depending on the
knowledge of the Englisch language the problems vary between 'why is
this word a metaphor for what?' and 'I thought this structure has all
the features and restrictions a stack normally has'.
Harald Lüßen
Francis Glassborow
en...@sea.ericsson.se> writes
>I agree that metaphors, when taken too literally rather than with a
>grain of salt, can defeat their own purpose. But your view would
>prohibit the use of metaphors altogether. A metaphor is never an exact
>match, for if it were, it would not be a metaphor anymore. Both
everyday
>and technical language are full of "inexact" metaphors.
And those that are 'poor' (very inexact) are actually better than those
that are close because they do not lead us down a trail without stop
signs. The danger is always when the newcomer thinks s/he understands
but does not. Another problem is that not everyone speaks English (some
speak even more arcane languages than American:) This leads to
translation. Proper nouns do not suffer in this way (though there can be
pronunciation problems, a Frenchman would pronounce Jeeves differently
from the way I do).
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Andrei Alexandrescu
> You're right, of course, but Andrei does bring levity to this
> thread. I enjoy his attempts -- fleeting as they are -- to
> protagonize or antagonize some of the names.
I had to look in the dictionary three times to understand your answer
above.
I'm not sure I fully did, yet in the end I decided to take it as a
compliment. As Latins said: "Sapiens vivit praesentibus laetus." (Latin
quotes are great for looking cult when you're not.)
Anyways, what I think is that we should achieve a consensus, and the
factors
that condition that consensus over a given name seem to be (in random
order):
1. Comprehensiveness. The name should be a large enough umbrella to
cover
many cases of what we today call RAII. If Bjarne said auto_ptr uses
RAII,
then auto_ptr uses RAII, because Bjarne invented the very term, as
another
poster pointed out.
2. Expressiveness. The name should be expressive enough to be caught up
quickly by newcomers and easy to remember for them. I disagree that a
dadaist-like way of choosing a name that's empty of meaning would work.
Words have weight, and we shoud leverage that weight.
3. Ease to write, read, and talk about. That's the most important point
of
failure of the RAII name imho.
4. Translatability and cultural independence. I noticed some people
would
like that a lot. FWIW, in my native language there is no word for
"undo".
(Also niece and grandchild are the same word :o).)
I think we should evaluate naming schemes according to such a pattern.
Incidentally, the names I like do pretty well according to the criteria
above: Finalizer (what about Terminator, huh? - your kids would like
that
and learn programming), and Do-Undo. Scoped is pretty good, but it's not
a
noun, so it fails 3 miserably and leads to factionalism ("scoped kitchen
sink").
***
Do-Undo (from now on I'll use Do-Undo manipulatively instead of RAII) is
almost always characterized by pairing some function calls. In fact,
that's
a rule in my coding standards: "Always use a class if pairing two calls
is
required" and "Never ask your client to issue function calls in pairs".
I think a name could suggest this guarantee of paired calls, but I
couldn't
find a good, terse one.
Andrei
Gerhard Menzl
> I agree with your sentiment, but doesn't "Scoped State" and its
> variants convey similar ideas and diversity, without resorting to
> culturally tied names?
One reason why I don't like Scoped State is that it sounds confusingly
like a variant of the State pattern of GoF fame.
Gerhard Menzl
Danil
> "John B. Breckenridge" wrote:
> >
> > <nmus...@my-deja.com> wrote in message news:8dei51$14l$1...@nnrp1.deja.com...
> > > I see a stronger distinction between classes that model state in a
> > > passive way and classes that perform actions. I would name the second,
> > > as you suggest Do-Undo, and the first Set-Reset.
> >
> > I like Do-Undo, but I prefer Store-Restore to Set-Reset.
>
> gain consensus for them, I'll get over it!
Out of curiosity, is there a reason that I haven't seen the term
"Rollback" used in this thread? It seems to express the action we are
expecting of the destructor and it also ties in neatly with Herb's
transactional exception handling discussions.
Danil
Owen Wengerd
> I agree with your sentiment, but doesn't "Scoped State" and its
> variants convey similar ideas and diversity, without resorting to
> culturally tied names?
My only complaint about "Scoped State" is that it's just a tad difficult
to annunciate. "Bounded State" is perhaps not quite as descriptive, but
easier to say. However, I'd like to suggest a new word: "Envelope".
"Envelope class", "envelope object", "envelope idiom", etc. My main
complaint with "envelope" is that it's almost *too* succinct -- but perhaps
it inspires someone else to come with a better variation. :)
--
Owen Wengerd
President, ManuSoft ==> http://www.manusoft.com
VP Americas, CADLock, Inc. ==> http://www.cadlock.com
Sam Lindley
> > just
> > the 'classes' you mention, but also of other well established patterns,
> > and
> > then choose a term which fits well within that taxonomy.
>
> examples within that taxonomy. I'm not sure what more you want.
I didn't make myself very clear. This is roughly what I was thinking...
Suppose, for instance, we decided it would be useful to categorise this
pattern along with the collection of patterns described in 'Design
Patterns'. We might deem it inappropriate to call the pattern 'Jeeves' as
all of the other pattern names are: a) descriptive, b) not proper names. If
we were looking at the name in a different context we may come to a
different conclusion.
Related to this is the fact that different people are bound to have
different ideas as to the applicability / scope of the pattern they are
trying to describe, so its not surprising there's disagreement over naming.
For example, some people have suggested 'Sentry' is inappropriate as this
term is already used in describing multithreaded systems. Others may argue
that that isn't relevant as we're considering a completely separate domain
(afterall 'Sentry' already has yet another meaning in data structures). It
may not be
possible for everyone to agree on the context, never mind the actual name.
> We need to reach a modicum of consensus before anyone publishes a
> new term. Once we have consensus, we can begin publishing the
> new name in this NG. There are also a number of authors who
> frequent this NG, so they will be able to use that new name, if
> we ever find one.
Assuming the authors don't just decide for themselves.
Has anyone suggested 'Insurance' or something similar?
Sam Lindley
John B. Breckenridge
"Gerhard Menzl" <gerhar...@sea.ericsson.se> wrote in message
news:38FEF702...@sea.ericsson.se...
> Except that German-speaking technicians tend to shy away from literal
> translations of English metaphors and devise complicated,
circumlocutory
> words instead, interesting terms such as "Kellerspeicher" (= cellar
> memory) for "stack" or "Nachrichtenüberlagerungsfenster" (= message
> overlay window) for "message box". I don't even want to imagine what
> Do-Undo would be corrupted to. :-)
Would it be easier if we used a term that wasn't English to begin with?
I'd been thinking about suggesting the term "Status Quo" for this idiom,
since it's about the destructors returning things to the way they were
before the objects were constructed.
Ian Knowles
>1. Comprehensiveness. The name should be a large enough umbrella to
>cover many cases of what we today call RAII...
>2. Expressiveness. The name should be expressive enough to be caught up
>quickly by newcomers and easy to remember for them. I disagree that a
>dadaist-like way of choosing a name that's empty of meaning would work.
>Words have weight, and we shoud leverage that weight.
>3. Ease to write, read, and talk about. That's the most important point
>of failure of the RAII name imho.
>4. Translatability and cultural independence. I noticed some people
>would like that a lot...
I think this is a pretty good criteria for naming patterns or idioms.
[snip]
>above: Finalizer (what about Terminator, huh? - your kids would like
>that and learn programming), and Do-Undo. Scoped is pretty good, but it's not
>a noun, so it fails 3 miserably and leads to factionalism ("scoped kitchen
>sink").
I think you can easily make "Scoped" a noun by adding "Object" (i.e.
it is a "Scoped Object"), however, I think as a prefix "Scoped" is
much better than "Do-Undo".
For example consider a "Scoped Object" that automatically provides a
"Yes" for all end-user prompts. I would name this class a
"ScopedYesToAll" and believe this reads quite well, however, if it
were named "DoUndoYesToAll" I can imagine that it might take a couple
of re-reads to even correctly parse.
To be even more perverse imagine a "Scoped Object" whose role is to
add Undo operations. I would name this a "ScopedAddUndo" - would you
think "DoUndoAddUndo" would be easily understood?
Regards,
Ian Knowles (remove the .nospam to reply)
Ye Olde Coder
robatgia...@one.net wrote:
> The thread titled, "Resource Acquisition Is Initialization
> Naming," has fragmented. Many folks were only willing to discuss
> RAII (as the subject suggested, of course). I kept trying to
> discuss another type of class, which I claim includes RAII. I
> want to find a name for that type of class.
>
>
> Thoughts? Diatribes? Rants? Suggestions?
>
I wonder if 'Shepherd Pattern' or 'Shepherd class' might not work for
this.
--
/\----|---------|
|| __o_________o_____
|| | Ye Olde Coder |
|| VVVVVVVVVVVVVVVVVV
Sent via Deja.com http://www.deja.com/
Before you buy.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Andrei Alexandrescu
news:Ys8M4.10018$5D.2...@ozemail.com.au...
> I think you can easily make "Scoped" a noun by adding "Object" (i.e.
> it is a "Scoped Object"), however, I think as a prefix "Scoped" is
> much better than "Do-Undo".
I stuck my fingers in my ears and I'm singing: "La-la-la-la-laaaaaa, I don't
hear you, la-la-la..."
> For example consider a "Scoped Object" that automatically provides a
> "Yes" for all end-user prompts. I would name this class a
> "ScopedYesToAll" and believe this reads quite well, however, if it
> were named "DoUndoYesToAll" I can imagine that it might take a couple
> of re-reads to even correctly parse.
Ah, I didn't think of that. So a supplemental criterion is: "Make the name
easy to combine with others in class names". I have to admit that Do-Undo is
not too shiny at this...
Andrei
Owen Wengerd
> this.
I like it! It sounds good, plus it stacks up pretty well against the
criteria that has been discussed. :)
--
Owen Wengerd
President, ManuSoft ==> http://www.manusoft.com
VP Americas, CADLock, Inc. ==> http://www.cadlock.com
Francis Glassborow
Breckenridge <jo...@dfma.com> writes
>Would it be easier if we used a term that wasn't English to begin with?
>
>I'd been thinking about suggesting the term "Status Quo" for this idiom,
>since it's about the destructors returning things to the way they were
>before the objects were constructed.
I have been thinking quite a bit about this naming thing (and BTW I
personally think that many of the current names for patterns are
unhelpful and only serve to keep the neophyte confused, like the
vocabularies of religious cabals). One reason that terms like 'stack'
work is that there really is only one reasonable way they can be used in
context. OTOH terms like 'static' are complete disasters because they
have too many meanings. When authors write sentences such as 'Global
names that are not specified as static (in code font) are static.' we
should see just how poor metaphor can be as a way of deriving
vocabulary.
I am not against metaphor in itself, but would add the requirement that
such vocabulary can only have a single reasonable meaning as 'jargon'.
We should also think very carefully about potential problems with
translation (even in the more literal sense of that word 'moving across'
or 'moving to another place'). For example the sentence 'I achieved my
objective through pure graft.' has distinctly different meanings
depending on your locality. :)
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Francis Glassborow
<ow...@manusoft.com> writes
> I like it! It sounds good, plus it stacks up pretty well against the
>criteria that has been discussed. :)
And I definitely do not. Shepherds have nothing to do with this idiom.
Shepherds take care of flocks and the very last thing they would dream
of doing is destroying them.
Marco Dalla Gasperina
"Francis Glassborow" <fra...@robinton.demon.co.uk> wrote in message
news:td9ObYAz...@robinton.demon.co.uk...
> I have been thinking quite a bit about this naming thing
I really haven't at all... until I heard someone say in
passing:
"You can take it with you."
and thought hmmm.
marco
Rob Stewart
>
> Rob Stewart <donot...@giage.com> wrote in message
> news:38FEFE89...@giage.com...
> > You're right, of course, but Andrei does bring levity to this
> > thread. I enjoy his attempts -- fleeting as they are -- to
> > protagonize or antagonize some of the names.
>
> I had to look in the dictionary three times to understand your answer
> above.
> I'm not sure I fully did, yet in the end I decided to take it as a
> compliment. As Latins said: "Sapiens vivit praesentibus laetus." (Latin
> quotes are great for looking cult when you're not.)
Allow me to translate the compliment:
You're right, of course, but Andrei brings humor to this
thread.
I enjoy his attempts -- even if they shift with the wind
sometimes
(as in from Finalizer to Do-Undo) -- to support and encourage
the
use of or downplay and discourage the use of some of the
names.
> Anyways, what I think is that we should achieve a consensus, and the
I agree, of course.
> factors
> that condition that consensus over a given name seem to be (in random
> order):
>
> 1. Comprehensiveness. The name should be a large enough umbrella to
> cover
> many cases of what we today call RAII. If Bjarne said auto_ptr uses
If it doesn't cover all cases, then it isn't a sufficiently large
umbrella.
> RAII,
> then auto_ptr uses RAII, because Bjarne invented the very term, as
> another
> poster pointed out.
Indeed.
> 2. Expressiveness. The name should be expressive enough to be caught up
> quickly by newcomers and easy to remember for them. I disagree that a
> dadaist-like way of choosing a name that's empty of meaning would work.
> Words have weight, and we shoud leverage that weight.
The Cheshire Cat technique probably didn't hold sway for very
long because the name was so unusual. However, it was
expressive, once you understood the derivation. Thus,
expressiveness is not all important; indeed, it suggests we need
to weight certain of these criteria as more or less important.
> 3. Ease to write, read, and talk about. That's the most important point
> of
> failure of the RAII name imho.
This includes its use in talking about classes that use it (as
Ian Knowles pointed out).
> 4. Translatability and cultural independence. I noticed some people
> would
> like that a lot. FWIW, in my native language there is no word for
> "undo".
I guess that's a strike against "Do/Undo", eh?
> (Also niece and grandchild are the same word :o).)
There's only so much we can do about broken languages! ;*)
> I think we should evaluate naming schemes according to such a pattern.
> Incidentally, the names I like do pretty well according to the criteria
> above: Finalizer (what about Terminator, huh? - your kids would like
> that
> and learn programming), and Do-Undo. Scoped is pretty good, but it's
not
> a
> noun, so it fails 3 miserably and leads to factionalism ("scoped
kitchen
> sink").
As Ian suggested, you don't talk about a "Do/Undo", you talk
about a "Do/Undo" class or object. Hence, the name we're looking
for should support usage as a noun (as in "Scoped Class",
"Excursion Class", or "Do/Undo Class") and as an adjective (as in
"Scoped Lock"). Both "Do/Undo" and "Excursion" fail this last
test (neither can be used as an adjective in front of another
name).
I just thought of some else in favor of naming this idiom rather
than just calling these things classes (as some have suggested).
This idiom intentially creates objects on the stack, in order to
ensure the dtor is called upon leaving the current scope.
Ordinary classes may be created on the free store without
deviating from their intended purpose. This also weighs in favor
of using "Scoped" as it is suggestive of *not* creating objects
of this type on the free store.
> Do-Undo (from now on I'll use Do-Undo manipulatively instead of RAII)
is
> almost always characterized by pairing some function calls. In fact,
> that's
> a rule in my coding standards: "Always use a class if pairing two calls
> is
> required" and "Never ask your client to issue function calls in pairs".
>
> I think a name could suggest this guarantee of paired calls, but I
> couldn't
> find a good, terse one.
If the name is too suggestive of pairs of actions (as is
"Do/Undo"), then the degenerate cases with, no "do" seem force
fitted into the idiom.
--
Robert Stewart | rob-at-giage-dot-com
Software Engineer | using std::disclaimer;
Giage, Ltd. | http://www.giage.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Rob Stewart
>
> Out of curiosity, is there a reason that I haven't seen the term
> "Rollback" used in this thread? It seems to express the action we are
> expecting of the destructor and it also ties in neatly with Herb's
> transactional exception handling discussions.
I'd say the reason is that you hadn't suggested it before now!
Seriously, this emphasizes the "undo" part, like "Finalizer" at
the expense, I think, of the "do" part.
I think the important issues are that we're talking about classes
intended to live on the stack in order that the compiler invokes
the dtor to undo whatever had been done. Whether the doing is
the client's job (as in std::auto_ptr) or the class' job, the
object will undo it. However, an important subset of these
classes do the work for the client, so the focus shouldn't be
just on the undoing.
Rob Stewart
>
> Rob:
>
> > I agree with your sentiment, but doesn't "Scoped State" and its
> > variants convey similar ideas and diversity, without resorting to
> > culturally tied names?
>
> My only complaint about "Scoped State" is that it's just a tad
difficult
> to annunciate. "Bounded State" is perhaps not quite as descriptive,
but
> easier to say. However, I'd like to suggest a new word: "Envelope".
> "Envelope class", "envelope object", "envelope idiom", etc. My main
> complaint with "envelope" is that it's almost *too* succinct -- but
perhaps
> it inspires someone else to come with a better variation. :)
This conjures Coplien's envelope-letter idiom for me.
Rob Stewart
>
> Rob Stewart wrote:
>
> > I agree with your sentiment, but doesn't "Scoped State" and its
> > variants convey similar ideas and diversity, without resorting to
> > culturally tied names?
>
> like a variant of the State pattern of GoF fame.
What about just "Scoped"? We can talk about "Scoped Classes" as
the category and specific types or instances as in, "Scoped
Lock", "Scoped Pointer", and "Scoped Color".
Rob Stewart
Not that I recall. Let's see. In life:
1. At some point in your life, you buy insurance (before
something happens).
2. You go on with your life.
3. If you get sick or die, the insurance company pays your
beneficiaries.
In code:
1. You enter a scope and create an object which may do something
to alter the state.
2. You do the rest of the function's work.
3. If the code throws an exception, returns, or leaves the scope,
the compiler destroys the object thus undoing the original action
for the enclosing scope.
This fits nicely. Do we then have "Insurance Classes"? That
works pretty well. Can you have an "Insurance Lock" or an
"Insurance Color"? I don't think the term fits terribly well
when used to describe a specific class or instance. "Scoped
Lock" and "Scoped Color" work better.
Keep thinking!
Rob Stewart
>
> In article <%nsM4.6512$t_3....@cletus.bright.net>, Owen Wengerd
> <ow...@manusoft.com> writes
> > I like it! It sounds good, plus it stacks up pretty well against
the
> >criteria that has been discussed. :)
>
> And I definitely do not. Shepherds have nothing to do with this idiom.
> Shepherds take care of flocks and the very last thing they would dream
> of doing is destroying them.
It's the compiler that destroys them, not the object!
Nevertheless, a shepherd does much more than take the sheep out
of the fold in the morning and return them at night. The
shepherd sleeps in the gate, rescues lost, injured, or threatened
sheep, and locates food and water for them. Consequently, I
agree that it doesn't work well.
TonyMc
and my message became unthreaded (somewhat ironic considering the
content). I'll try again.
I wanted to suggest Ariadne class as a suggestive name for what has
been known as RAII. Ariadne lays down a thread which enables her to
find her way out of the labyrinth. She provides the information
necessary to undo a journey, however complicated.
I think the name Ariadne class is succinct and suggestive and less
culturally specific than Jeeves. Any thoughts?
Tony
Owen Wengerd
> And I definitely do not. Shepherds have nothing to do with this idiom.
Well, I happen to disagree, but weren't you the one arguing that an
unrelated name is a *good* thing?
> Shepherds take care of flocks and the very last thing they would dream
> of doing is destroying them.
No, they don't destroy their flock (perhaps we need a new name for
destructors... <g>) -- shepherds ensure that they return with each and every
animal they left with. Looking at the "Do-Undo" idiom from the point of
view of the client code, there is no "destroying" taking place: something
(i.e. a resource) is entrusted to the care of some object, and the object
guarantees that eveything in its care will be properly and completely
"returned" when the client code goes out of scope. I think it's almost
perfect.:)
Owen Wengerd
President, ManuSoft ==> http://www.manusoft.com
VP Americas, CADLock, Inc. ==> http://www.cadlock.com
Dave Abrahams
fra...@robinton.demon.co.uk wrote on 4/24/00 6:20 PM:
> And I definitely do not. Shepherds have nothing to do with this idiom.
> Shepherds take care of flocks and the very last thing they would dream
> of doing is destroying them.
The term "terrorist" sprang to mind (i.e. something that kills its
hostage(s) before it dies). Do you think that has too many negative
connotations? ;)
-Dave
nmus...@my-deja.com
robatgia...@one.net wrote:
[...]
> I think the important issues are that we're talking about classes
> intended to live on the stack in order that the compiler invokes
> the dtor to undo whatever had been done. Whether the doing is
> the client's job (as in std::auto_ptr) or the class' job, the
> object will undo it. However, an important subset of these
> classes do the work for the client, so the focus shouldn't be
> just on the undoing.
This is exactly why I suggested (or wanted to suggest) calling them
"classes with automatic semantics", just like we speak of pointer vs.
value semantics. This is not as catchy as the GOF pattern names, but I
consider it consistent with the latter two terms.
Best regards,
Nicola Musatti
Sent via Deja.com http://www.deja.com/
Before you buy.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Hendrik Schober
> [...]
> I wanted to suggest Ariadne class as a suggestive name for what has
> been known as RAII. Ariadne lays down a thread which enables her to
> find her way out of the labyrinth. She provides the information
> necessary to undo a journey, however complicated.
>
> I think the name Ariadne class is succinct and suggestive and less
> culturally specific than Jeeves. Any thoughts?
IMHO it is still pretty culturally specific (e.g.
think of Asian cultures), it's only that many
cultures taking part in this thread share this as
a root of their culture.
However, despite the fact that I knew who Ariadne
was and what she is famous for, it will take some
explanation to understand what an Ariadne class
does.
While Francis seems to like those, I'd rather have
a name where, if I had to ask at all, the only
question would be: "Is this the one I think it is?"
Both "Finalizer" and "Do/Undo" come close to this,
the just suggested "rollback" seems to fit this
exactly.
> Tony
Schobi
--
bitb...@gmx.de is never read
I'm hschober at gmx dot de
Hendrik Schober
> [...]
> Out of curiosity, is there a reason that I haven't seen the term
> "Rollback" used in this thread? It seems to express the action we are
> expecting of the destructor and it also ties in neatly with Herb's
> transactional exception handling discussions.
I think I've seen the word "rollback" in the other
thread Rob startet on this (hey Rob, now you took
all attention to this new thread, and basically
we're discussing the same things as we did in the
old one...), only nodoby picked it up and suggested
it.
Actually it sounds good to me. (If only we could get
Andrei to not hating it... You never know.) But since
this seems to be the second one I really like (or was
it the third already?) after I voted for one term
beeing "the right term", I tend to be a bit more
reserved...
What's the rest of the crowd thinking about this one?
> Danil
Hendrik Schober
> Andrei Alexandrescu wrote:
> [...]
> The Cheshire Cat technique probably didn't hold sway for very
> long because the name was so unusual. However, it was
> expressive, once you understood the derivation. Thus,
> expressiveness is not all important; indeed, it suggests we need
> to weight certain of these criteria as more or less important.
I disagree. Someone explained the term to me just a
few weeks ago and I already forgot it. OTOH, I seem
to miss the funny thing in "Pimple", and the term
"Compiler Firewall" needed clarification, too (Is it
what I think it is?), but still I'm able to remember
and use it easyly.
> [...]
> As Ian suggested, you don't talk about a "Do/Undo", you talk
> about a "Do/Undo" class or object. Hence, the name we're looking
> for should support usage as a noun (as in "Scoped Class",
> "Excursion Class", or "Do/Undo Class") and as an adjective (as in
> "Scoped Lock"). Both "Do/Undo" and "Excursion" fail this last
> test (neither can be used as an adjective in front of another
> name).
Mhmm. Adjective, eh?
The "Done/Undone Lock"?
;^)
> [...]
> Robert Stewart | rob-at-giage-dot-com
Danil
> I'd say the reason is that you hadn't suggested it before now!
>
> Seriously, this emphasizes the "undo" part, like "Finalizer" at
> the expense, I think, of the "do" part.
I guess I'm not convinced that shouldn't be the goal. After all, we've
already got plenty of do's - the bugs come from not remembering to put
things back the way we found them.
Hmm. . . . boomerangs fly back to where they started - at least until
you are good enough to hit something with them. That might be a better
match for do/undo than homing pigeons.
When I think about the fact that we aren't trying to do anything
permanent, I end up groping for something like Cinderella's Pumpkin
Carriage.
How about Newton's Third Law: "For every action, there is an equal and
opposite reaction". A little clumsy, as the purpose of these objects is
to ensure that law still holds. But I think it expresses the paired
complementary functions better than YinYan, or Evil Twin Skippy.
Andrei Alexandrescu
> What about just "Scoped"? We can talk about "Scoped Classes" as
> the category and specific types or instances as in, "Scoped
> Lock", "Scoped Pointer", and "Scoped Color".
No, no! I got it! "Transactioned Resource". The Transactioned Resource
Idiom. Ah, sounds so nice. Like the title of a PhD thesis.
But I remembered resource is too specific to be acceptable. Well it was a
thought.
Andrei
Rob Stewart
>
> I wanted to suggest Ariadne class as a suggestive name for what has
> been known as RAII. Ariadne lays down a thread which enables her to
> find her way out of the labyrinth. She provides the information
> necessary to undo a journey, however complicated.
>
> I think the name Ariadne class is succinct and suggestive and less
> culturally specific than Jeeves. Any thoughts?
I don't see how it's less culturally specific because of its
reference to an ancient myth. I had never heard of Ariadne
before you brought it up. It is specific to (I'm guessing) the
Greek empire of old. Therefore, only time makes the difference.
However, I'll concede that, based only upon the explanation
you've given, Ariadne fits better than Jeeves, simply because she
does some arbitrarily complex thing and can "undo" it by
retracing her steps. That's the same idea I thought was in
"Excursion".
If there's more to Ariadne than you've given, then those more
familiar with her may raise objections due to the additional
associations.
--
Robert Stewart | rob-at-giage-dot-com
Software Engineer | using std::disclaimer;
Giage, Ltd. | http://www.giage.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Hendrik Schober
> [...]
> However, I'll concede that, based only upon the explanation
> you've given, Ariadne fits better than Jeeves, simply because she
> does some arbitrarily complex thing and can "undo" it by
<nitpicking>
It wasn't Ariadne herself who undid. She gave
the thread to her lover so that he could get
out of the labyrinth, after he killed the
beast.
</nitpicking>
I don't know what this implies for applying her
name to RAII.
> [...]
> Robert Stewart | rob-at-giage-dot-com
Schobi
--
bitb...@gmx.de is never read
I'm hschober at gmx dot de
Francis Glassborow
<da...@ultranet.com> writes
>Hmm. . . . boomerangs fly back to where they started - at least until
>you are good enough to hit something with them. That might be a better
>match for do/undo than homing pigeons.
I feel some affinity to calling them boomerang classes. The metaphor is
weak but usable. It is also amusing because you are using precisely to
avoid being hit (unexpectedly). BTW there are straight line boomerangs
that are designed not to return but have an extended range (I believe
the record is over 400 yards)
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
TonyMc
wrote:
> <nitpicking>
> It wasn't Ariadne herself who undid. She gave
> the thread to her lover so that he could get
> out of the labyrinth, after he killed the
> beast.
> </nitpicking>
>
> I don't know what this implies for applying her
> name to RAII.
Thank you for the nitpick (or picked nit). Yes, I recall that Theseus
was the one who used Ariadne's thread to get out again, not Ariadne
herself. It's just that the story is generally remembered as
"Ariadne's thread" (is this an Ariadne thread?).
Maybe the nitpick helps the idiom. Ariadne provides the backtracking
information, but the quest is Theseus'. In the same way, in the RAII
idiom, the smart pointer (or other resource manager) is only a helper.
The resource bit is the quest, after all.
But then, if you push a metaphor too far you start looking for
something like curtains for windows or chewing gum under your
desktop...
Regards, Tony
Rob Stewart
>
> "Rob Stewart" <donot...@giage.com> wrote:
> >
> > The Cheshire Cat technique probably didn't hold sway for very
> > long because the name was so unusual. However, it was
> > expressive, once you understood the derivation. Thus,
> > expressiveness is not all important; indeed, it suggests we need
> > to weight certain of these criteria as more or less important.
>
> I disagree. Someone explained the term to me just a
> few weeks ago and I already forgot it. OTOH, I seem
OK, so I'm familiar with Alice in Wonderland, so it sticks easily
with me. You, obviously, have to remember the relevant parts of
Alice in Wonderland *and* the application of Cheshire Cat to
C++. I can see your problem.
> to miss the funny thing in "Pimple", and the term
Assuming you know the derivation of "pimple" from "pimpl" and
what "pimpl" refers to, I can only guess that you don't know the
other meaning of "pimple". Assuming that's the case, I'll tell
you: a pimple is a single acne skin eruption. That is, a pimple
is the reddened and swollen skin surrounding a clogged pore.
So, it's just "funny" that the "Pimple" technique uses the same
word as a skin blemish.
> "Compiler Firewall" needed clarification, too (Is it
> what I think it is?), but still I'm able to remember
> and use it easyly.
That's a good point. The term is fairly expressive.
> > [...]
> > As Ian suggested, you don't talk about a "Do/Undo", you talk
> > about a "Do/Undo" class or object. Hence, the name we're looking
> > for should support usage as a noun (as in "Scoped Class",
> > "Excursion Class", or "Do/Undo Class") and as an adjective (as in
> > "Scoped Lock"). Both "Do/Undo" and "Excursion" fail this last
> > test (neither can be used as an adjective in front of another
> > name).
>
> Mhmm. Adjective, eh?
> The "Done/Undone Lock"?
> ;^)
Well...OK. We can probably coerce anything that way, but is that
a good plan?
--
Robert Stewart | rob-at-giage-dot-com
Software Engineer | using std::disclaimer;
Giage, Ltd. | http://www.giage.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Rob Stewart
>
> donot...@giage.com says...
> > Seriously, this emphasizes the "undo" part, like "Finalizer" at
> > the expense, I think, of the "do" part.
>
> I guess I'm not convinced that shouldn't be the goal. After all, we've
> already got plenty of do's - the bugs come from not remembering to put
> things back the way we found them.
That is critically important. There's no question about that.
However, talking just about the dtor's role leads us back to
RAII. But what about a class that sets the mouse pointer to an
hourglass icon, then resets it to the original later? Setting
the pointer in the ctor is exactly half the reason such a class
exists. (You can argue that a more general class allows you to
specify the icon to set, but then the client must specifically
set -- and remember the syntax for -- the desired icon.)
> Hmm. . . . boomerangs fly back to where they started - at least until
> you are good enough to hit something with them. That might be a better
> match for do/undo than homing pigeons.
I like it. "Boomerang Classes". A "Boomerang Cursor". A
"Boomerang File".
> When I think about the fact that we aren't trying to do anything
> permanent, I end up groping for something like Cinderella's Pumpkin
> Carriage.
Oops! There's that cultural tie.
Rob Stewart
>
> Rob Stewart <donot...@giage.com> wrote in message
> news:3905B53A...@giage.com...
> > What about just "Scoped"? We can talk about "Scoped Classes" as
> > the category and specific types or instances as in, "Scoped
> > Lock", "Scoped Pointer", and "Scoped Color".
>
> No, no! I got it! "Transactioned Resource". The Transactioned Resource
> Idiom. Ah, sounds so nice. Like the title of a PhD thesis.
>
> But I remembered resource is too specific to be acceptable. Well it was a
> thought.
Why do we need the word "Resource" in there? Why not
"Transactioned Class"? Then you get "Transactioned Lock" and
"Transactioned Color". However, does this offer us much
improvement over "Scoped"? It is certainly harder to write and
say.
Rob Stewart
>
> "Rob Stewart" <donot...@giage.com> wrote:
> > [...]
> > However, I'll concede that, based only upon the explanation
> > you've given, Ariadne fits better than Jeeves, simply because she
> > does some arbitrarily complex thing and can "undo" it by
> > retracing her steps. [...]
>
> It wasn't Ariadne herself who undid. She gave
> the thread to her lover so that he could get
> out of the labyrinth, after he killed the
> beast.
> </nitpicking>
Oh, great! Now we have a whole different idiom: a class that
passes off its work to another to undo.
You're supposed to be helping Hendrik! ;o)
> I don't know what this implies for applying her
> name to RAII.
We're not naming RAII in this thread!
Hendrik Schober
> what "pimpl" refers to,
Yes. I know that.
> I can only guess that you don't know the
> other meaning of "pimple".
Right. I didn't get this.
> Assuming that's the case, I'll tell
> you: a pimple is a single acne skin eruption. That is, a pimple
> is the reddened and swollen skin surrounding a clogged pore.
Oh, that's one of those words they don't teach you
in English classes. ;^> I think I've heard it
before, but there are so many words...
> [...]
> Robert Stewart | rob-at-giage-dot-com
Schobi
--
bitb...@gmx.de is never read
I'm hschober at gmx dot de
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Hendrik Schober
> Danil wrote:
> [...]
> However, talking just about the dtor's role leads us back to
> RAII. But what about a class that sets the mouse pointer to an
> hourglass icon, then resets it to the original later? Setting
> the pointer in the ctor is exactly half the reason such a class
> exists. (You can argue that a more general class allows you to
> specify the icon to set, but then the client must specifically
> set -- and remember the syntax for -- the desired icon.)
I see them as a superset of those things you'd call RAII,
or an extension to RAII, or a specialization of RAII...
I still don't see why they're so fundamentally different
from RAII. Oh well, you don't pass the curser, the ctor
picks it. So what? The main point is, that the dtor will
undo this.
If this wasn't the main goal, nobody would use a class
for it.
> > Hmm. . . . boomerangs fly back to where they started - at least until
> > you are good enough to hit something with them. That might be a better
> > match for do/undo than homing pigeons.
>
> I like it. "Boomerang Classes". A "Boomerang Cursor". A
> "Boomerang File".
To me a "boomerang" is something you did although you
knew you are supposed to not to do it and afterwards it
turned out that doing it you hit yourself.
That's quite a negative meaning.
But that's only my culture, I guess.
> > When I think about the fact that we aren't trying to do anything
> > permanent, I end up groping for something like Cinderella's Pumpkin
> > Carriage.
>
> Oops! There's that cultural tie.
Aschenputtels Kürbiswagen???
Well, this thread seems to start to be fun. (Or funny?)
Hendrik Schober
> Hendrik Schober wrote:
>
> You're supposed to be helping Hendrik! ;o)
I try really hard, you know... ;^>
> > I don't know what this implies for applying her
> > name to RAII.
>
> We're not naming RAII in this thread!
There seems to be no agreement about this. Once
again I'd really like the inventor of the term
to give an exact definition of it.
Chris Booth
<donot...@giage.com> writes
<snip>
>1. You enter a scope and create an object which may do something
>to alter the state.
>2. You do the rest of the function's work.
>3. If the code throws an exception, returns, or leaves the scope,
>the compiler destroys the object thus undoing the original action
>for the enclosing scope.
>
>This fits nicely. Do we then have "Insurance Classes"? That
>works pretty well. Can you have an "Insurance Lock" or an
>"Insurance Color"? I don't think the term fits terribly well
>when used to describe a specific class or instance. "Scoped
>Lock" and "Scoped Color" work better.
>
>Keep thinking!
tentative ?
--
Chris Booth
nmus...@my-deja.com
in computer science, which doesn't fit in here. Specifically, Do/Undo
classes do not provide the commit/rollback alternative.
Best regards,
Nicola Musatti
Sent via Deja.com http://www.deja.com/
Before you buy.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Rob Stewart
>
> "Rob Stewart" <donot...@giage.com> wrote:
> > Danil wrote:
> > [...]
> > However, talking just about the dtor's role leads us back to
> > RAII. But what about a class that sets the mouse pointer to an
> > hourglass icon, then resets it to the original later? Setting
> > the pointer in the ctor is exactly half the reason such a class
> > exists. (You can argue that a more general class allows you to
> > specify the icon to set, but then the client must specifically
> > set -- and remember the syntax for -- the desired icon.)
>
> I see them as a superset of those things you'd call RAII,
> or an extension to RAII, or a specialization of RAII...
Certainly.
> I still don't see why they're so fundamentally different
> from RAII. Oh well, you don't pass the curser, the ctor
> picks it. So what? The main point is, that the dtor will
> undo this.
> If this wasn't the main goal, nobody would use a class
> for it.
I agree that w/o the dtor, our discussion would be moot. But, if
we pick a word that only refers to that action, then -- in my
mind -- it doesn't fit well the classes designed to do all the
work. Apparently, I use lots of classes that do all the work and
you don't. Thus, we have different perspectives on the
appropriate breadth of the name.
> > > Hmm. . . . boomerangs fly back to where they started - at least
until
> > > you are good enough to hit something with them. That might be a
better
> > > match for do/undo than homing pigeons.
> >
> > I like it. "Boomerang Classes". A "Boomerang Cursor". A
> > "Boomerang File".
>
> To me a "boomerang" is something you did although you
> knew you are supposed to not to do it and afterwards it
> turned out that doing it you hit yourself.
> That's quite a negative meaning.
> But that's only my culture, I guess.
Is that an ordinary word or a slang word in German, or just your
connotation of the word "boomerang"? I only think of the curved
(usually) wooden device that you throw it and it returns. (I
don't even think of it as a weapon that's supposed to fell an
animal.) So, it has the exact meaning for me.
Will we ever find something that works for us all?
> > > When I think about the fact that we aren't trying to do anything
> > > permanent, I end up groping for something like Cinderella's Pumpkin
> > > Carriage.
> >
> > Oops! There's that cultural tie.
>
> Aschenputtels Kürbiswagen???
Is that German for Cinderella's Pumpkin or for a vehicle in a
similar story?
> Well, this thread seems to start to be fun. (Or funny?)
It's all been fun, hasn't it?
--
Robert Stewart | rob-at-giage-dot-com
Software Engineer | using std::disclaimer;
Giage, Ltd. | http://www.giage.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Rob Stewart
> >1. You enter a scope and create an object which may do something
> >to alter the state.
> >2. You do the rest of the function's work.
> >3. If the code throws an exception, returns, or leaves the scope,
> >the compiler destroys the object thus undoing the original action
> >for the enclosing scope.
>
> tentative ?
That suggests that it may not happen, doesn't it? The intent is
that it does happen, then it's reset.
Rob Stewart
> >
> > > I don't know what this implies for applying her
> > > name to RAII.
> >
> > We're not naming RAII in this thread!
>
> There seems to be no agreement about this. Once
RAII has been pretty well established, in that *other* thread, to
be about the dtor. It's about releasing resources. Whether it
includes more is still up for debate.
> again I'd really like the inventor of the term
> to give an exact definition of it.
I agree. I assume Bjarne is just trying to stay away from the
monster I created!
Anyway, I think there are two differences between RAII and what I
want to name:
1. RAII is concerned with resources; I claim there are things
besides resources (properties, at least) to which doing then
undoing apply.
2. RAII is concerned with releasing a resource. The "classes
that do then undo" can have non-trivial "do" actions. Some have
argued that RAII includes classes that acquire the resource, too,
but that isn't necessary to have RAII.
The difference is sufficient to want a name broader than RAII.
Hendrik Schober
> we pick a word that only refers to that action, then -- in my
> mind -- it doesn't fit well the classes designed to do all the
> work. Apparently, I use lots of classes that do all the work and
> you don't. Thus, we have different perspectives on the
> appropriate breadth of the name.
I use quite a few Classes That Do then Undo (TM). But
I use them for their dtor's task. Sigh... ;^>
I hoped for BS to explain what he considered RAII to
be when he coined the term, but he doesn't seem to
read this thread.
> [...]
> > To me a "boomerang" is something you did although you
> > knew you are supposed to not to do it and afterwards it
> > turned out that doing it you hit yourself.
> > That's quite a negative meaning.
> > But that's only my culture, I guess.
>
> Is that an ordinary word or a slang word in German, or just your
> connotation of the word "boomerang"? I only think of the curved
> (usually) wooden device that you throw it and it returns. (I
> don't even think of it as a weapon that's supposed to fell an
> animal.) So, it has the exact meaning for me.
Well, a boomerang seems to be a device that, when thrown
and not disturbed in its flight, will come back to you.
Out of this formed a (probably slangy) idiom in my language.
> Will we ever find something that works for us all?
It's not that I wouldn't get used to boomerang. But,
especially since I emphasize the dtor's part, I like
terms as Finalizer, Rollback etc. a lot better.
> > > > When I think about the fact that we aren't trying to do anything
> > > > permanent, I end up groping for something like Cinderella's
Pumpkin
> > > > Carriage.
> > >
> > > Oops! There's that cultural tie.
> >
> > Aschenputtels Kürbiswagen???
>
> Is that German for Cinderella's Pumpkin or for a vehicle in a
> similar story?
Er...ahem...mhmm...I'm not sure...
> > Well, this thread seems to start to be fun. (Or funny?)
>
> It's all been fun, hasn't it?
Mostly, sure. Yet we don't have something that enough of us
can agree upon.
(Why not? Finalizers seem good, Rollback seems good, Do-Undo
seems clumsy to me but would do it... From everyone of those
most people would immediatly understand what is meant. That's
what I think, at least...)
> Robert Stewart | rob-at-giage-dot-com
Schobi
--
bitb...@gmx.de is never read
I'm hschober at gmx dot de
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Hendrik Schober
> > again I'd really like the inventor of the term
> > to give an exact definition of it.
>
> I agree. I assume Bjarne is just trying to stay away from the
> monster I created!
>
> Anyway, I think there are two differences between RAII and what I
> want to name:
;^>
> [...] The "classes
> that do then undo" can have non-trivial "do" actions. Some have
> argued that RAII includes classes that acquire the resource, too,
> but that isn't necessary to have RAII.
They are just classes that mess up something and use
<include your favority synonym for RAII> to clean up
after them, IMHO.
> [...]
John Potter
wrote:
> I hoped for BS to explain what he considered RAII to
> be when he coined the term, but he doesn't seem to
> read this thread.
He did make a post in the original thread. Reading it again may
explain some things. It should answer one of those.
John
John Potter
wrote:
> They are just classes that mess up something and use
> <include your favority synonym for RAII> to clean up
> after them, IMHO.
You've got it! A messer_upper_fixer_later. That should
translate back to German as nicely as it translated to
English (I will not understand it, but I am sure I will
appreciate it). OK Rob, now get some author to publish
it and we can all use it. :)
Heinz Huber
Mark Rodgers wrote:
>
> Rob Stewart <donot...@giage.com> wrote
> > Jeeves (eliciting great praise and consternation)
>
> An excellent suggestion!
What's this Jeeves stuff about. I keep reading it in messages.
Heinz
Hendrik Schober
> On 2 May 2000 12:48:11 -0400, "Hendrik Schober" <bitb...@gmx.de>
> wrote:
>
> > I hoped for BS to explain what he considered RAII to
> > be when he coined the term, but he doesn't seem to
> > read this thread.
>
> He did make a post in the original thread. Reading it again may
> explain some things. It should answer one of those.
It seems that not only me, but also Deja must have missed
that post. The only one I can remember (and I can find in
Deja) is the one where he (replying to Francis) says that
it is not easy to find good names and that meanwhile RAII
is so widespread that introducing alternatives would only
increase confusion. There's no definition of RAII, though.
What am I missing?
> John
Schobi
--
bitb...@gmx.de is never read
I'm hschober at gmx dot de
Gerhard Menzl
> You've got it! A messer_upper_fixer_later. That should
> translate back to German as nicely as it translated to
> English (I will not understand it, but I am sure I will
> appreciate it).
That would be a ... let me see ...
Durcheinanderbringer_spaeter_Aufraeumer.
Nothing in IT translates nicely into German. I really think we shouldn't
burden an already difficult discussion with translatability issues.
Gerhard Menzl
John Hickin
>
> increase confusion. There's no definition of RAII, though.
You will find the definition in
The Annotated C++ Reference Manual
Page 358 at the bottom.
M.A. Ellis and B. Stroustrup
Addison Wesley, 1990.
ISBN 0-201-51459-1
which I partially quote:
The fundamental idea is to represent the acquisition of a resource
as the initialization of a local variable and then rely on
the execution of the destructor to release that resource.
I've seen the opinion that things like auto_ptr<> are not RAII because
the constructor does not necessarily acquire the resource; the
destructor merely releases any previously acquired resource; Finalizer
was a nice name for this. IMHO, however, this is still RAII; the
constructor is considered to acquire a trivial resource. Many people
don't balk at the idea of trivial lock; why not admit the possibility of
a trivial resource?
We have all seen the file close example too. Here RAII is generalized to
the point where the destructor does not necessarily release the
resource; it tries to close and on failure it abandons the resource to a
garbage collection thread (to ensure this may succeed, the constructor
has to acquire an _undo_ resource from the GC thread much like unix
applications may ask for a semaphore undo in a semop).
Regards, John.
John Potter
wrote:
> "John Potter" <jpo...@falcon.lhup.edu> wrote:
> > On 2 May 2000 12:48:11 -0400, "Hendrik Schober" <bitb...@gmx.de>
> > wrote:
> >
> > > I hoped for BS to explain what he considered RAII to
> > > be when he coined the term, but he doesn't seem to
> > > read this thread.
> >
> > He did make a post in the original thread. Reading it again may
> > explain some things. It should answer one of those.
>
> It seems that not only me, but also Deja must have missed
> that post. The only one I can remember (and I can find in
> Deja) is the one where he (replying to Francis) says that
> it is not easy to find good names and that meanwhile RAII
> is so widespread that introducing alternatives would only
> increase confusion. There's no definition of RAII, though.
> What am I missing?
The fact that it answers why he is not reading this thread. :)
John
Andrei Alexandrescu
news:391016AA...@elbanet.co.at...
> What's this Jeeves stuff about. I keep reading it in messages.
Ah, nothing. A simple typo. A moment of madness. A mistake. Nothing at
all.
At a moment, somehow someone proposed it as an uninspired name for the
idiom that's well-known as Do-Undo.
Andrei
Rob Stewart
>
> On 2 May 2000 13:11:15 -0400, "Hendrik Schober" <bitb...@gmx.de>
> wrote:
>
> > They are just classes that mess up something and use
> > <include your favority synonym for RAII> to clean up
> > after them, IMHO.
>
> translate back to German as nicely as it translated to
> English (I will not understand it, but I am sure I will
> it and we can all use it. :)
That gets us another acronym, too: MUFL. You can even pronouce
that one! All right, who will be first to publish it?
--
Robert Stewart | rob-at-giage-dot-com
Software Engineer | using std::disclaimer;
Giage, Ltd. | http://www.giage.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Rob Stewart
>
> Slightly ;-) off-topic, but of great interest to me.
>
> Mark Rodgers wrote:
> >
> > Rob Stewart <donot...@giage.com> wrote
> > > Jeeves (eliciting great praise and consternation)
> >
> > An excellent suggestion!
>
>From the other RAII Naming thread, "Jeeves" was introduced due to
its connection with a fictional character of some novels(?). He
was a "gentleman's gentleman," so to speak, and was often left to
clean up after his employer made a mess of things.
Those more familiar with the character will probably elect to
give you a better description.
The interesting thing is, despite my unfamiliarity with the
character and stories, I have been able to retain its application
to this thread. That makes it a decent name for me. Others may
have a harder time remember the story behind the name and, thus,
the meaning of "Jeeves".
nmus...@my-deja.com
"Andrei Alexandrescu" <andre...@hotmail.com> wrote:
> Heinz Huber <Heinz...@elbanet.co.at> wrote in message
> news:391016AA...@elbanet.co.at...
>
> all.
Ah, Andrei, perseverare diabolicus...
>
> At a moment, somehow someone proposed it as an uninspired name for the
> idiom that's well-known as Do-Undo.
You obviously mean "Shuttle Classes".
Best regards,
Nicola Musatti
Sent via Deja.com http://www.deja.com/
Before you buy.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Sam Lindley
template<typename T>
class ScopeGuard
{
private:
T& var;
T val;
public:
ScopeGuard(T& var) : var(var), val(var) {}
~ScopeGuard() {var = val;}
};
--
Sam Lindley ;-)
Hendrik Schober
> [...]
> The Annotated C++ Reference Manual
> which I partially quote:
>
> The fundamental idea is to represent the acquisition of a resource
> as the initialization of a local variable and then rely on
> the execution of the destructor to release that resource.
It's probably just that my English isn't good
enough but to me this seems to leave room for
different interpretations of what "the acquisition
of a resource as the initialization of a [...]
variable" means. Is it that the aqusition takes
place in the initialization finction (the ctor)
or will the resource be passed to it?
> [...]
> Regards, John.
Schobi
--
bitb...@gmx.de is never read
I'm HSchober at gmx dot de
Rob Stewart
>
> "John Hickin" <hic...@nortelnetworks.com> wrote:
> > [...]
> > The Annotated C++ Reference Manual
> > [...]
> > which I partially quote:
> >
> > The fundamental idea is to represent the acquisition of a resource
> > as the initialization of a local variable and then rely on
> > the execution of the destructor to release that resource.
> > [...]
>
> It's probably just that my English isn't good
> enough but to me this seems to leave room for
> different interpretations of what "the acquisition
> of a resource as the initialization of a [...]
> variable" means. Is it that the aqusition takes
> place in the initialization finction (the ctor)
> or will the resource be passed to it?
My English is quite good, and I find it equally vague. I have to
assume it was purposely vague, thus allowing for various
interpretations. The rest of us -- including me -- have applied
personal biases and experience to restrict it.
--
Robert Stewart | rob-at-giage-dot-com
Software Engineer | using std::disclaimer;
Giage, Ltd. | http://www.giage.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Rob Stewart
>
> Is this class well-named?
>
> template<typename T>
> class ScopeGuard
> {
> private:
> T& var;
> T val;
> public:
> ScopeGuard(T& var) : var(var), val(var) {}
> ~ScopeGuard() {var = val;}
> };
I don't think so. There is nothing in the name that suggests
that the variable passed to the ctor will be reset to its
original value. Something like ScopedValue or GuardedValue would
work better.
Also, since T is a template parameter, assignment may be
expensive. Shouldn't the dtor compare to see whether the reset
is needed? I realize that means T must have operator ==()
defined, and the ctor already copies a T, but it might be a
useful change. (You could just as easily document that a T will
be copy constructed and assigned, leaving it to the client to
decide whether they want that overhead.)
Mike Wahler
I've been following this thread with interest (but
haven't made a contribution, other than a couple
attempts at humor :-) )
But after some thought, I was reminded of my days
in the Boy Scouts, where we were constantly
reminded: "Leave your campsite as you found it."
At first I was going to suggest "Boy Scout class,"
but that has the undesired cultural reference. So
how about "fastidious" or the shorter "tidy" ?
To me this connotes "clean up any messes made",
and isn't restricted to resource acquistion/release.
-Mike
Mike Wahler
TonyMc <af...@btinternet.com> wrote in message
news:l60hgsgn8e87r908e...@4ax.com...
> But then, if you push a metaphor too far you start looking for
> something like curtains for windows or chewing gum under your
> desktop...
So *that's* what's wrong with this darn Windows machine. :-)
C>razorblade.exe
Hey thanks, it works now. :-)
Mike Wahler
Owen Wengerd <ow...@manusoft.com> wrote in message
news:880M4.6151$t_3....@cletus.bright.net...
> However, I'd like to suggest a new word: "Envelope".
> "Envelope class", "envelope object", "envelope idiom", etc. My main
> complaint with "envelope" is that it's almost *too* succinct -- but
perhaps
> it inspires someone else to come with a better variation. :)
Actually, this seems almost the same as calling it an
'encapsulated' class, which I rejected for obvious
reasons.:-)
Rob Stewart
>
> But after some thought, I was reminded of my days
> in the Boy Scouts, where we were constantly
> reminded: "Leave your campsite as you found it."
>
> At first I was going to suggest "Boy Scout class,"
> but that has the undesired cultural reference. So
The bane of all good names so far!
> how about "fastidious" or the shorter "tidy" ?
>
> To me this connotes "clean up any messes made",
> and isn't restricted to resource acquistion/release.
This fits the general theme represented by names like:
o Butler
o Janitor
o Jeeves (yes, Andrei, Jeeves!)
o Stewar(t|d)
--
Robert Stewart | rob-at-giage-dot-com
Software Engineer | using std::disclaimer;
Giage, Inc. | http://www.giage.com
Mike Wahler
Rob Stewart <donot...@giage.com> wrote in message
news:3924014F...@giage.com...
> Mike Wahler wrote:
> >
> > But after some thought, I was reminded of my days
> > in the Boy Scouts, where we were constantly
> > reminded: "Leave your campsite as you found it."
> >
> > At first I was going to suggest "Boy Scout class,"
> > but that has the undesired cultural reference. So
>
> The bane of all good names so far!
>
> > how about "fastidious" or the shorter "tidy" ?
> >
> > To me this connotes "clean up any messes made",
> > and isn't restricted to resource acquistion/release.
>
> This fits the general theme represented by names like:
>
> o Butler
A butler generally cleans up *other* people's messes. :-)
> o Janitor
Other people's messes.
> o Jeeves (yes, Andrei, Jeeves!)
Not familiar with this one.
> o Stewar(t|d)
I believe that's spelled 'steward'
Other people's messes.
Tidy X --- X makes mess, cleans up own mess.
-Mike
Gerhard Menzl
> > o Butler
>
> A butler generally cleans up *other* people's messes. :-)
Which is precisely what auto_ptr, for instance, does. There are RAII
classes that make the mess themselves, and others that don't, and then
there is the mess that ensues when people start discussing whether the
latter is really RAII at all. Oh no, here we go again ...
> > o Jeeves (yes, Andrei, Jeeves!)
>
> Not familiar with this one.
It's a handy device for infuriating exiled Romanian template smiths. Its
effect is similar to that of garlic on vampires at a distance of one
inch.
> > o Stewar(t|d)
>
> I believe that's spelled 'steward'
Not by Rob. In a linguistic sense, a Stewart class would be similar to
Koenig lookup (which should really be spelled "König", by the way). I
like the immortalizing side-effect.
Gerhard Menzl
Jack J. Woehr
for something which holds an enduring value and restores it
to its owner is Escrow.
Rob Stewart wrote:
> Sam Lindley wrote:
> >
> > Is this class well-named?
> >
> > template<typename T>
> > class ScopeGuard
> > {
> > private:
> > T& var;
> > T val;
> > public:
> > ScopeGuard(T& var) : var(var), val(var) {}
> > ~ScopeGuard() {var = val;}
> > };
>
> I don't think so. There is nothing in the name that suggests
> that the variable passed to the ctor will be reset to its
> original value. Something like ScopedValue or GuardedValue would
> work better.
--
Jack J. Woehr # Ceterum censeo
PO Box 51, Golden, CO 80402 # in herbas belli
http://www.well.com/~jax/rcfb # ab idem desistamus.
Bruce DeVisser
> Tidy X --- X makes mess, cleans up own mess.
Good name.
As a suggestion for describing the strict 'I will take make a point of
doing The Right Thing at destruction time' trait, let me take your
suggestion and mutilate it for my own nefarious purposes. ;)
I suggest 'Todo' -- which in itself is somewhat suggestive -- but
which also stands for 'Tidy-up On Destruction Operation.'
--
- Bruce
Rob Stewart
>
> Mike Wahler wrote:
>
> > > o Butler
> >
> > A butler generally cleans up *other* people's messes. :-)
A butler also creates the mess by providing the means with which
to make the mess (or overseeing its provision). For example, the
butler (usually by oversight) sets the table, serves the food,
etc., then cleans the mess created by those partaking.
> Which is precisely what auto_ptr, for instance, does. There are RAII
> classes that make the mess themselves, and others that don't, and then
> there is the mess that ensues when people start discussing whether the
> latter is really RAII at all. Oh no, here we go again ...
Where's that Butler Class that cleans up after opening Pandora's
box? I had here a minute ago....
> > > o Jeeves (yes, Andrei, Jeeves!)
> >
> > Not familiar with this one.
>
> It's a handy device for infuriating exiled Romanian template smiths. Its
> effect is similar to that of garlic on vampires at a distance of one
> inch.
That's just too funny!
(BTW, in case Gerhard's description doesn't clarify the matter,
let me quote Barry Wallis' post:
The original Jeeves was the prototypical butler to Bertie
Wooster
(both were characters created by P. G. Wodehouse). Jeeves'
function
in life was to fix up the messes into which Wooster was
constantly
entangling himself.
Thus, Jeeves fixed messes. It would seem that Bertie Wooster was
the one making the messes to be cleaned, so Jeeves didn't create
the condition he had to fix.
> > > o Stewar(t|d)
> >
> > I believe that's spelled 'steward'
>
> Not by Rob. In a linguistic sense, a Stewart class would be similar to
> Koenig lookup (which should really be spelled "König", by the way). I
> like the immortalizing side-effect.
I like that idea. You like that idea. Let's just assume
everyone else does and start calling them Stewart Classes! ;O)
--
Robert Stewart | rob-at-giage-dot-com
Software Engineer | using std::disclaimer;
Giage, Inc. | http://www.giage.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Mike Wahler
news:3924EAED...@ibm.net...
> I would suggest that perhaps the figurative English name
> for something which holds an enduring value and restores it
> to its owner is Escrow.
[pulls lever] Yes, I like it! 'Escrow' gets my vote.
-Mike
Rob Stewart
>
> Jack J. Woehr <jwo...@ibm.net> wrote in message
> news:3924EAED...@ibm.net...
> > I would suggest that perhaps the figurative English name
> > for something which holds an enduring value and restores it
> > to its owner is Escrow.
>
> [pulls lever] Yes, I like it! 'Escrow' gets my vote.
Refer to the summary thread I started, which posits evaluation
criteria. Escrow doesn't fit well when naming instances. That
is, what is a Lock Escrow? It also doesn't fit well when naming
classes: what is an Escrow Lock?
--
Robert Stewart | rob-at-giage-dot-com
Software Engineer | using std::disclaimer;
Giage, Inc. | http://www.giage.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]