"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ak5oq2$1vqe$1@digitaldaemon.com...
> I for one had almost given up on D due to the lack of exactly those two features.  It seemed at the time that Walter was dead set against them.
Now
> that operator overloading is in and templates are going in soon, I'm definitely going to have to take another crack at it.  Good debugger
support
> would help immensely; that's probably the next big thing on my list.

The only significant language thing now is the deterministic object destruction.

On Fri, 23 Aug 2002 10:12:23 -0700 "Walter" <walter@digitalmars.com> wrote:

> The only significant language thing now is the deterministic object destruction.

Also, templates now have to be actually _implemented_. =)
I would also mention safe varargs as one quite important feature. Propety
gettors &
settors - but these are mostly decorative.

In article <CFN374919407791782@news.digitalmars.com>, Pavel Minayev says...
>
>On Fri, 23 Aug 2002 10:12:23 -0700 "Walter" <walter@digitalmars.com> wrote:
>
>> The only significant language thing now is the deterministic object destruction.
> 
>Also, templates now have to be actually _implemented_. =)
>I would also mention safe varargs as one quite important feature. Propety
>gettors &
>settors - but these are mostly decorative.
> 

Just looked at the "Classes" topic in the documentation, where I found the following description.  It looks like property gettors/settors to me, but there may be a finer distinction of which I am unaware.  I also have not done much D programming, so it may be that the following has been described but not yet implemented...

Mac

(remainder of posting is quoted from the docs)
" All this is quite a bit of typing, and it tends to make code unreadable by
filling it with getProperty() and setProperty() calls. In D, get'ers and set'ers
take advantage of the idea that an lvalue is a set'er, and an rvalue is a
get'er:

class Abc
{	int myprop;
void property(int newproperty) { myprop = newproperty; } // set'er
int property() { return myprop; }	// get'er
}


which is used as:

Abc a;
a.property = 3;		// equivalent to a.property(3)
int x = a.property;		// equivalent to int x = a.property()


Thus, in D you can treat a property like it was a simple field name. A property can start out actually being a simple field name, but if later if becomes necessary to make getting and setting it function calls, no code needs to be modified other than the class definition."

"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374919407791782@news.digitalmars.com...
> On Fri, 23 Aug 2002 10:12:23 -0700 "Walter" <walter@digitalmars.com>
wrote:
> > The only significant language thing now is the deterministic object destruction.
> Also, templates now have to be actually _implemented_. =)

Ah, boring implementation details <g>.

> I would also mention safe varargs as one quite important feature.

While they would be nice, I'd have to disagree as to their importance. Varargs isn't used much outside of printf, whereas some people wrap their whole program design around d.o.d.

> Propety
> gettors &
> settors - but these are mostly decorative.

Yes.

"Walter" <walter@digitalmars.com> wrote in news:ak5qb3$21dc$2 @digitaldaemon.com:

> 
> "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ak5oq2$1vqe$1@digitaldaemon.com...
>> I for one had almost given up on D due to the lack of exactly those two features.  It seemed at the time that Walter was dead set against them.
> Now
>> that operator overloading is in and templates are going in soon, I'm definitely going to have to take another crack at it.  Good debugger
> support
>> would help immensely; that's probably the next big thing on my list.
> 
> The only significant language thing now is the deterministic object destruction.
> 
> 

Walter if you did put in a language level reference counting mechanism for deterministic object destruction you would be a mega super hero.

Reflection comes in second on the list for me.

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns9273A36B24E83patcodemooncom@63.105.9.61...
> Walter if you did put in a language level reference counting mechanism for deterministic object destruction you would be a mega super hero.

I did suddenly realize that d.o.d. naturally falls out of reference counting, but reference counting does not fall out of d.o.d., which is why it is so clumsy and error prone to do reference counting in C++.

On Fri, 23 Aug 2002 19:02:44 +0000 (UTC) Mac Reiter <Mac_member@pathlink.com> wrote:

> programming, so it may be that the following has been described but not yet implemented...

Exactly. It is just not yet implemented...

"Walter" <walter@digitalmars.com> wrote in news:ak6f6p$2oan$1@digitaldaemon.com:

> 
> "Patrick Down" <pat@codemoon.com> wrote in message news:Xns9273A36B24E83patcodemooncom@63.105.9.61...
>> Walter if you did put in a language level reference counting mechanism for deterministic object destruction you would be a mega super hero.
> 
> I did suddenly realize that d.o.d. naturally falls out of reference counting, but reference counting does not fall out of d.o.d., which is why it is so clumsy and error prone to do reference counting in C++.

Yes but I think you should call it d.o.f. Deterministic Object Finalization.  Here's why.

What I think would be a good idea is not to call the objects destuctor (~A) when the refCount==0 but to call a different function. Perhaps unref().  If a user want's the full memory cleanup they can call "delete this".

The reason is you can use it to implement other memory management schmes on top of the mark and sweep.  If I am allocating and deallocating a lot of small objects quickly I might want to do object pooling.

class Foo : Counted
{
  static Foo head;
  static Foo alloc()
  {
    Foo temp;
    if(head)
    {
      temp = head;
      head = temp.next;
    }
    else
      temp = new Foo();
  }
  void unref()
  {
    this.next = head;
    head = this;
  }
  private next;
}



{
  Foo a = Foo.alloc()

} // a's unref returns it to the free pool

Yes, it should wind up calling the finalizer.

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns9274526F5BFB6patcodemooncom@63.105.9.61...
> "Walter" <walter@digitalmars.com> wrote in news:ak6f6p$2oan$1@digitaldaemon.com:
>
> >
> > "Patrick Down" <pat@codemoon.com> wrote in message news:Xns9273A36B24E83patcodemooncom@63.105.9.61...
> >> Walter if you did put in a language level reference counting mechanism for deterministic object destruction you would be a mega super hero.
> >
> > I did suddenly realize that d.o.d. naturally falls out of reference counting, but reference counting does not fall out of d.o.d., which is why it is so clumsy and error prone to do reference counting in C++.
>
> Yes but I think you should call it d.o.f. Deterministic Object Finalization.  Here's why.
>
> What I think would be a good idea is not to call the objects destuctor (~A) when the refCount==0 but to call a different function. Perhaps unref().  If a user want's the full memory cleanup they can call "delete this".
>
> The reason is you can use it to implement other memory management schmes on top of the mark and sweep.  If I am allocating and deallocating a lot of small objects quickly I might want to do object pooling.
>
> class Foo : Counted
> {
>   static Foo head;
>   static Foo alloc()
>   {
>     Foo temp;
>     if(head)
>     {
>       temp = head;
>       head = temp.next;
>     }
>     else
>       temp = new Foo();
>   }
>   void unref()
>   {
>     this.next = head;
>     head = this;
>   }
>   private next;
> }
>
>
>
> {
>   Foo a = Foo.alloc()
>
> } // a's unref returns it to the free pool
>

I would very much like that but it's not something that would prevent me from using D.  I can always manually delete things.  But performance wise it's much better if the compiler knows when things are going out of scope and just deletes them immediately, or even better knows this and allocates them on the stack instead.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:ak5qb3$21dc$2@digitaldaemon.com...
>
> "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ak5oq2$1vqe$1@digitaldaemon.com...
> > I for one had almost given up on D due to the lack of exactly those two features.  It seemed at the time that Walter was dead set against them.
> Now
> > that operator overloading is in and templates are going in soon, I'm definitely going to have to take another crack at it.  Good debugger
> support
> > would help immensely; that's probably the next big thing on my list.
>
> The only significant language thing now is the deterministic object destruction.