Newbie initial comments on D language - scope

Edward Diener eddielee_no_spam_here at tropicsoft.com
Sat Feb 2 11:59:07 PST 2008


Walter Bright wrote:
> Edward Diener wrote:
>>
>> Voila ! You now have a full GC language in which both the class 
>> designer, via a 'scope' class, and the object creator, via a 'scope' 
>> object, has complete control over the destruction of objects. Yours 
>> would be the first GC language to really solve the problem of objects 
>> encapsulating non-memory resources being destroyed deterministically 
>> when references to the object are no longer being used. All other GC 
>> languages just gloss over the problem or maintain that it occurs so 
>> rarely there is no need for anything but manual release of non-memory 
>> resources ( via try/catch and specialized Dispose/Close ) or 
>> semi-manual methods such as your current very limited use of 'scope'.
>>
>> I hear you saying, "No I don't want to be the first GC language to 
>> solve this problem especially as Java, .Net, Python, Ruby, et al.  
>> just pretend
>> it does not exist or is unimportant for practical programming and 
>> besides, it is difficult to solve and I have lots of other, better 
>> things to do, and finally few people will know or give me credit for 
>> it anyway." But somewhere, some day, someone is going to point out 
>> this flaw in GC and a solution, as I have described, will be 
>> implemented, and then everyone will say, "why did we not think of this 
>> sooner". And some bright person will say, "you know Walter Bright 
>> solved this years ago with D."
> 
> We did think of it over a year ago, and have been laying the groundwork 
> for it (wanted to get the const madness done first). This will enable D 
> to be, as you say, the first language to support the triumvirate of 
> explicit, automatic, and ref counted memory allocation on an equal footing.

That would be superb !

> 
> The only question is whether the proxy struct will be easy enough to use 
> to not need extra core language support:
> 
>      scope C c;
> 
> v.s.:
> 
>      Scope!(C) c;

I would like to see:

C c = new C(...);

and if C is a 'scope' class it is handled exactly the same as:

scope C c = new C(...);

if C is not a scope class. In both cases the 'c' object gets reference 
counted and treated as such when it is copied, assigned, and leaves a D 
scope in order to have its destructor called immediately when there are 
no more references to it. In other words I do not like the imposition of 
having to treat C as a struct which the form of:

scope C c;

implies nor of having to specify 'scope' if the class itself has already 
been marked as 'scope' in the class definition.

The idea in my mind is essentially that 'scope' classes automatically 
define an object that, when used exactly as an normal GC object, 
automatically calls the destructor of the object just as soon as the 
last reference to it goes out of scope. In this sense the user neither 
know or cares whether the object encapsulates a resource or not and uses 
an object of such a class just as he would use any other GC object. 
Similarly the user can force an object to be a 'scope' object through 
the second syntax give above, but from then on he treats the object just 
as he would any other GC object.

My point of view is quite simply the the core D language should make the 
syntax for using 'scope' objects as non-distinguishable from using 
normal GC objets as possible. Having a different way just to instantiate 
an object of a 'scope' class is not as it removes the transparency of 
their use.

> 
> One major consideration arguing for it to be a library feature is 
> multithreading. Doing locked reference counts is slow, and needed only 
> for a minority of objects. It should be selectable when you allocate the 
> object whether you need it multithreaded or not.

Please take a look at atomic operations, which I am sure you already 
know about. I believe boost::shared_ptr<T> in its latest incarnation is 
  using it to increment and decrement the reference count without the 
usual time penalty which you mention.



More information about the Digitalmars-d mailing list