Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Naming Classes That Do then Undo (was: RAII Naming)

9 views
Skip to first unread message

Rob Stewart

unread,
Apr 14, 2000, 3:00:00 AM4/14/00
to
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.

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

unread,
Apr 16, 2000, 3:00:00 AM4/16/00
to
Rob Stewart <donot...@giage.com> wrote in message
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

unread,
Apr 16, 2000, 3:00:00 AM4/16/00
to
Rob Stewart <donot...@giage.com> 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.

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

unread,
Apr 17, 2000, 3:00:00 AM4/17/00
to
In article <sfhhsrn...@news.supernews.com>, Andrei Alexandrescu
<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

unread,
Apr 17, 2000, 3:00:00 AM4/17/00
to
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.

Best regards,
Nicola Musatti


Sent via Deja.com http://www.deja.com/
Before you buy.

Francis Glassborow

unread,
Apr 17, 2000, 3:00:00 AM4/17/00
to
In article <38F727D1...@giage.com>, Rob Stewart
<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

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
<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.

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

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
Francis Glassborow wrote:

> 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

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
"Rob Stewart" <donot...@giage.com> wrote in message
news:38F727D1...@giage.com...
> 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.

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

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
On 19 Apr 2000 05:45:27 -0400, Gerhard Menzl
<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

--
Harald....@gmx.de

Francis Glassborow

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
In article <38FD662C...@sea.ericsson.se>, Gerhard Menzl <gerhard.m
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

unread,
Apr 21, 2000, 3:00:00 AM4/21/00
to
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.)

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

unread,
Apr 21, 2000, 3:00:00 AM4/21/00
to
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?

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

unread,
Apr 21, 2000, 3:00:00 AM4/21/00
to
donot...@giage.com says...

> "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.
>
> I don't care much for the hyphenated names, but, hey, if we can
> 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

unread,
Apr 22, 2000, 3:00:00 AM4/22/00
to
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. :)
--
Owen Wengerd
President, ManuSoft ==> http://www.manusoft.com
VP Americas, CADLock, Inc. ==> http://www.cadlock.com

Sam Lindley

unread,
Apr 22, 2000, 3:00:00 AM4/22/00
to
> > 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.
>
> I created a taxonomy of the types of classes, not a catalog of
> 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

unread,
Apr 22, 2000, 3:00:00 AM4/22/00
to

"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

unread,
Apr 22, 2000, 3:00:00 AM4/22/00
to
"Andrei Alexandrescu" <andre...@hotmail.com> wrote:

>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

unread,
Apr 22, 2000, 3:00:00 AM4/22/00
to
In article <38F727D1...@giage.com>,

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.
>
[snip]
>
> 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

unread,
Apr 23, 2000, 3:00:00 AM4/23/00
to
Ian Knowles <i...@who.net.nospam> wrote in message
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

unread,
Apr 23, 2000, 3:00:00 AM4/23/00
to
> I wonder if 'Shepherd Pattern' or 'Shepherd class' might not work for
> 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

unread,
Apr 24, 2000, 3:00:00 AM4/24/00
to
In article <Kz1M4.43723$MZ2.5...@news1.wwck1.ri.home.com>, John B.
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

unread,
Apr 24, 2000, 3:00:00 AM4/24/00
to
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.

Marco Dalla Gasperina

unread,
Apr 25, 2000, 3:00:00 AM4/25/00
to

"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

unread,
Apr 25, 2000, 3:00:00 AM4/25/00
to
Andrei Alexandrescu wrote:
>
> 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

unread,
Apr 25, 2000, 3:00:00 AM4/25/00
to
Danil wrote:
>
> 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

unread,
Apr 25, 2000, 3:00:00 AM4/25/00
to
Owen Wengerd wrote:
>
> 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

unread,
Apr 25, 2000, 3:00:00 AM4/25/00
to
Gerhard Menzl wrote:

>
> 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?
>
> One reason why I don't like Scoped State is that it sounds confusingly
> 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

unread,
Apr 25, 2000, 3:00:00 AM4/25/00
to

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

unread,
Apr 25, 2000, 3:00:00 AM4/25/00
to
Francis Glassborow wrote:
>
> 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

unread,
Apr 25, 2000, 3:00:00 AM4/25/00
to
Sorry, I pressed the wrong key when trying to follow up this thread
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

unread,
Apr 25, 2000, 3:00:00 AM4/25/00
to
Francis:

> 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

unread,
Apr 26, 2000, 3:00:00 AM4/26/00
to
in article BB4FMlAj...@robinton.demon.co.uk, Francis Glassborow at
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

unread,
Apr 26, 2000, 3:00:00 AM4/26/00
to
In article <3905B454...@giage.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

unread,
Apr 26, 2000, 3:00:00 AM4/26/00
to
"TonyMc" <af...@btinternet.com> wrote:
> [...]

> 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

unread,
Apr 26, 2000, 3:00:00 AM4/26/00
to
"Danil" <da...@ultranet.com> wrote:
> [...]

> 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

unread,
Apr 26, 2000, 3:00:00 AM4/26/00
to
"Rob Stewart" <donot...@giage.com> wrote:
> 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

unread,
Apr 26, 2000, 3:00:00 AM4/26/00
to
donot...@giage.com says...

> 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

unread,
Apr 26, 2000, 3:00:00 AM4/26/00
to
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.


Andrei

Rob Stewart

unread,
Apr 26, 2000, 3:00:00 AM4/26/00
to
TonyMc wrote:
>
> 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

unread,
Apr 27, 2000, 3:00:00 AM4/27/00
to
"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. [...]

<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

unread,
Apr 27, 2000, 3:00:00 AM4/27/00
to
In article <MPG.13700005d...@enews.newsguy.com>, Danil
<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 ]