constness for arrays

[Andrew Fedoniouk]

"Don Clugston" <dac at nospam.com.au> wrote in message 
news:e9qb6h$2r4m$1 at digitaldaemon.com...
> Andrew Fedoniouk wrote:
>> Don, I think that reference counting (MOO COW) has the
>> same set of "civil rights" as GC so probably it makes sense
>> to look on this from language design perspective in more universal
>> fashion. RefCounting of arrays is only one particular thing I mean -
>> language shall support this idiom with the same quality as GC.
>
> I agree that something more universal would be better. But there's a 
> really interesting feature: when you have GC, you don't need full 
> reference counting, because you don't need deterministic destruction. You 
> only need a single bit. (I think this is correct, but it needs more 
> thought).

"But there's a really interesting feature: when you have GC, you don't need 
full
reference counting, because you don't need deterministic destruction."

Theoretically, yes. Practically... I would change it to
"when you have perfect GC".

And about GC:

Here is the sample I know pretty well:
There is no HTML rendering engine in the wild based on GC  memory
management ( http://en.wikipedia.org/wiki/List_of_layout_engines )

I've seen attempts to do them in Java or C# - not even close.
(In Harmonia I've decided to do not use GC heap for the DOM too)

Deterministic memory management has one and big benefit - it is
manageable and predictable.


>
>> In fact for typical and effective refcounting implementation it is
>> enough to have ctors/dtors/assignement in structs.
>
> I don't quite agree with this. I think that arrays in D are fundamentally 
> different from arrays in C/C++. In C, they're little more than syntactic 
> sugar for pointers, whereas in D, they are more like very important, 
> built-in structs. If refcounting were more integral in the language, it 
> would need to be available for built-in arrays.
>
>> Having them MOO COW can be implemented easily without
>> need of runtime model changes.
>>
>> And MOO COW is somehow orthogonal to constness.
>
> Yes, that's the point I was trying to make. I thought it was an 
> interesting proposal, but doesn't have much to do with compile-time 
> constness, except insofar as it reduces the need for full const.

There is a string struct in Harmonia using such bit (string.d):

struct tstring(CHAR)
{
  CHAR[]  chars;
  bit     mutable = true; // by default empty string is mutable
  ......
}

and this is exactly wat was propsed (except of placement of the bit)

Without constness and ability to define methods it worth nothing for
arrays.

>
>> Again, I would try to find here more universal solution
>> rather than particular array problem.
>>
>> I beleive that "smart pointer" as an entity will cover
>> MOO COW cases. But D does not have facilities
>> now for smart pointers at all.
>
> Walter seems to have vehement opposition to operator =. I wonder if it is 
> really necessary. Maybe a single opXXX() function could do the job, if the 
> compiler had some extra intelligence. (Much as opCmp does all of the >,<, 
>  >=, <=. Every op= and copy constructor I've ever seen in C++ was  very 
> tedious, I wonder if that design pattern could be factored into a single 
> function).

operator "="  IS really necessary.  As there is no method in D
currently to guard assignment to variable (memory location).
Again without it good chunk of RAII methods and smart pointers
are not implementable in D.

In HTMLayout SDK I have dom::element object which is wrapper
around internal DOM element handler. It is in C++.
I physically cannot write something close and so easy to use in D.

**DOM element.*/

    class element
    {
    protected:
      HELEMENT he;
      void use(HELEMENT h) { he = (HTMLayout_UseElement(h) == HLDOM_OK)? h: 
0; }
      void unuse() { if(he) HTMLayout_UnuseElement(he); he = 0; }
      void set(HELEMENT h) { unuse(); use(h); }
    public:
      element(): he(0) { }
      element(HELEMENT h)       { use(h); }
      element(const element& e) { use(e.he); }
      operator HELEMENT() const { return he; }
      ~element()                { unuse(); }
      element& operator = (HELEMENT h) { set(h); return *this; }
      element& operator = (const element& e) { set(e.he); return *this; }
      ....
}