From 5555489092723274811
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,fbe10986a90d9275
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 2004-01-23 18:00:00 PST
Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!crtntx1-snh1.gtei.net!chcgil2-snh1.gtei.net!news.bbnplanet.com!nycmny1-snf1.gtei.net!news.gtei.net!colt.net!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull
From: omarshaikh71@yahoo.com (Omar Shaikh)
Newsgroups: comp.std.c++
Subject: Re: Proposal for adding two keywords for explicit modification
Date: Sat, 24 Jan 2004 01:59:55 +0000 (UTC)
Lines: 148
Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++)
Message-ID: <20040123123254.47354.qmail@web20901.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: mail2news.demon.co.uk 1074909595 1720 10.0.0.1 (24 Jan 2004 01:59:55 GMT)
X-Complaints-To: abuse@demon.net
NNTP-Posting-Date: Sat, 24 Jan 2004 01:59:55 +0000 (UTC)
X-Received: from mulga.cs.mu.oz.au ([128.250.1.22])
	by news.demon.co.uk with esmtp (Exim 4.12)
	id 1AkD5W-0000Ra-00
	for mail2news@news.news.demon.net; Sat, 24 Jan 2004 01:59:54 +0000
X-Received: from mulga.cs.mu.OZ.AU (localhost [127.0.0.1]) by mulga.cs.mu.OZ.AU with ESMTP
	id i0O1xql5027791; Sat, 24 Jan 2004 12:59:52 +1100 (EST)
X-Received: (from fjh@localhost)
	by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id i0O1xq8W027781;
	Sat, 24 Jan 2004 12:59:52 +1100 (EST)
X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f
X-Path: comp-std-cpp-robomod!not-for-mail
X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov)
X-Delivered-To: std-c++@ucar.edu
X-Spam-Status: No, hits=1.0 required=5.2 tests=FROM_ENDS_IN_NUMS autolearn=no 
	version=2.60-mulga_r1
X-Spam-Checker-Version: SpamAssassin 2.60-mulga_r1 (1.212-2003-09-23-exp) on 
	mulga.cs.mu.OZ.AU
X-Newsgroups: comp.std.c++
Xref: archiver1.google.com comp.std.c++:944

Any new feature in any language is bound to break a
small amount of legacy code.

However, there are some very real situations where a
feature of this sort makes would make sense and, in
fact, could even be a life-saver.

Consider the following code.

void f ()
{
	freeze int i = 0;

	...

	while (1) {
		...
		thaw ++i;
		if (i = some_val) // Error! Cannot
		                  // modify a frozen
				  // without thawing
			break;
	}

	return 0;
}

To implement these keywords, one merely has to modify
any variable that acts as an iterator within a loop
(like i above) to freezable. Next compile that
(compilation) unit and check for syntax errors, which
the (supporting) compiler is sure to generate. One has
to run through the code to next see where i has to be
actually thawed and modified: all other errors are
bugs. A very simple feature; a feature however that
makes life easier for the programmer.

The whole issue is about choice, letting the
programmer use a type that is modifiable when he wants
it to be modifiable, and a const when it should be a
const. Another way of looking at this feature is a way
of extending data hiding to primitive types (though
this feature would be available to non-primitives
too). "thaw" is nothing except the equivalent of a
mutator without the overhead of a mutator call (all
right, agreed that mutators can be inlined; however,
there are other benefits, too; for example, there's no
need for the programmer to create his own mutators for
immediate assignment since they are built into the
language).

It could even be considered as a "shortcut mutator."
For example,

	struct Bar
	{
		int i;
		freeze double d;

		Bar () : d(10.0) {}
	};

	...

	void f () {
		freeze Bar b;

		b.i = 10; // Error!
		thaw b.i = 10; // Works fine
		thaw b.d = 3.14; // Error! Though object b has
thawed, Foo::d hasn't
		thaw (b.d) = 3.14; // thaw both simultaneously and
assign
	}

The basic idea of a freezable is that the compiler
prevents the user code from modifying the bitwise
layout of a frozen object, unless it is modified by
thaw.

It could also be used for read-only access in a class,
like a property.

	class Bar
	{
	public:
		freeze bool isActive;

		Bar () : isActive(true) {}

		...
	};

	void f () {
		Bar bar;

		if (bar.isActive) {
			...
		}
	}

However, since Bar::isActive is a frozen within Bar,
it can be safely exposed without any associated risk
of inadvertent modification by the client code.
(Recall from my previous posting that a freezable can
be referenced only by a more restrictive type outside
its block.)

	void e (int x) {
		// ...
	}

	void f (int& x) {
		// ...
	}

	void g (freeze int& x) {
		// ...
	}

	void h (const int& x) {
		// ...
	}

	void caller () {
		freeze int v = 10;
		e(v); // Works fine, since only passing by value
		f(v); // Error! Cannot read into lower restriction
		g(v); // Error! Not restrictive enough
		h(v); // Works fine, since const is more restrictive
	}

	// ...

I look forward to more comments and suggestions.
Omar

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]