|
Re: Mutable Types
|
Posted: Feb 3, 2006 6:42 AM
|
|
> > The problem is that hard-wiring things like const, or > > non-null pointers, or regions (ala Cyclone), introduce > > significant complexity into a language design. These > Hm, do you mean to say that this:
<snip>
> is more elegant than:
<snip>
No. I said the language design is simpler. The lanugage specification however would be considerably simplified.
The syntax proposed here is more intended to be demonstrative of the underlying processes. I am looking at ways to improve on it. One possibility is that "def" is actually a template class, so perhaps we would write instead:
public { def<Initialization> Init() { } def Fu() { } def<Const> Bar() { } }
The assertions could then be hidden in the constructors of the various specializations of the def template. > To me, having a lot of asserts at the beginning of a > function, rather than using language abstractions like > constructors and "const" as part of the type system, is > more inelegant.
But what if you want two stage constructors, or to distinguish between logical and physical constness? What if you want to label non-constness, rather than constness. Or what if you want new categories of functions, such as "published", which might mean that it is made available externally using some kind of RMI mechanism. There are other abstractions one can imagine, above and beyond initialization and const. If you simply solve each problem one by one, you are no closer to the goal of a language which can adapt easily to new paradigms. > In your version, if someone forgets to use > "assert(is_initialised(this))" at the start of a function, > they risk operating on uninitialised data, invoking > possibly undefined behaviour. By initialising the object > in the constructor, you don't run the risk of using an > uninitialised object.
The problem with the constructor approach, is the issue that some objects have trivial constructors, and some objects don't. Detecting this is hard, and makes it hard to write truly generic algorithms. Too often I see C++ classes which are optimized for POD's etc.
> Furthermore, having all these > asserts lead to duplication.
It's just long-hand. There are more convenient syntaxes one could imagine.
> This seems more like a pre C++-system (like C, where you > don't have constructors or "const"), than a post-C++ > one...
Sure, I'll buy that. Improvement on C++, doesn't neccessarily entail moving forward in the same directions. But I do like constructors, and Heron does have them, I simply want every object to have a default constructor.
|
|