December 20, 2011
On 12/20/2011 11:57 AM, bearophile wrote:
> Timon Gehr:
>
>> If you don't need virtual functions, you should probably use
>> structs instead of classes. (you are not doing OOP anyway.)
>
> I don't agree with both that statements.
>
> Bye,
> bearophile

1. He does not want type info. Structs don't have type info. He does not want virtual functions. Structs don't support virtual functions. Ergo he should use mostly structs. Please defend your disagreement.

2. Dynamic binding is a core concept of OOP. A language that does not support dynamic binding does not support OOP. A program that does not use dynamic binding is not object oriented. What is to disagree with?
December 20, 2011
On Tuesday, December 20, 2011 15:49:34 Timon Gehr wrote:
> 2. Dynamic binding is a core concept of OOP. A language that does not support dynamic binding does not support OOP. A program that does not use dynamic binding is not object oriented. What is to disagree with?

I don't agree with that either. You don't need polymorphism for OOP. It's quite restricted without it, but you can still program with objects even if you're restricted to something like D's structs, so you're still doing OOP.

- Jonathan M Davis
December 20, 2011
On 12/20/2011 05:36 PM, Jonathan M Davis wrote:
> On Tuesday, December 20, 2011 15:49:34 Timon Gehr wrote:
>> 2. Dynamic binding is a core concept of OOP. A language that does not
>> support dynamic binding does not support OOP. A program that does not
>> use dynamic binding is not object oriented. What is to disagree with?
>
> I don't agree with that either. You don't need polymorphism for OOP. It's
> quite restricted without it, but you can still program with objects even if
> you're restricted to something like D's structs, so you're still doing OOP.
>
> - Jonathan M Davis

No. That is glorified procedural style. 'Objects' as in 'OOP' carry data and _behavior_, structs don't (except if you give them some function pointers, but that is just implementing poor man's polymorphism.)

Having some kind of dynamic execution model is a requirement for OOP. There are no two ways about it.
December 20, 2011
On Tuesday, December 20, 2011 17:58:30 Timon Gehr wrote:
> On 12/20/2011 05:36 PM, Jonathan M Davis wrote:
> > On Tuesday, December 20, 2011 15:49:34 Timon Gehr wrote:
> >> 2. Dynamic binding is a core concept of OOP. A language that does not support dynamic binding does not support OOP. A program that does not use dynamic binding is not object oriented. What is to disagree with?
> > 
> > I don't agree with that either. You don't need polymorphism for OOP.
> > It's
> > quite restricted without it, but you can still program with objects even
> > if you're restricted to something like D's structs, so you're still
> > doing OOP.
> > 
> > - Jonathan M Davis
> 
> No. That is glorified procedural style. 'Objects' as in 'OOP' carry data and _behavior_, structs don't (except if you give them some function pointers, but that is just implementing poor man's polymorphism.)
> 
> Having some kind of dynamic execution model is a requirement for OOP. There are no two ways about it.

Well, I completely disagree. The core of OOP is encapsulating the data within an object and having functions associated with the object itself which operate on that data. It's about encapsulation and tying the functions to the type. Polymorphism is a nice bonus, but it's not required.

I'd say that any language which is really trying to do OOP should definitely have polymorphism or it's going to have pretty sucky OOP, but it can still have OOP.

- Jonathan M Davis
December 20, 2011
Timon Gehr:

> What is to disagree with?

Sorry for my precedent answer, please ignore it, sometimes I have a too much big mouth. I think discussions about definitions are not so interesting.

Bye,
bearophile
December 20, 2011
On 12/20/2011 06:41 PM, Jonathan M Davis wrote:
> On Tuesday, December 20, 2011 17:58:30 Timon Gehr wrote:
>> On 12/20/2011 05:36 PM, Jonathan M Davis wrote:
>>> On Tuesday, December 20, 2011 15:49:34 Timon Gehr wrote:
>>>> 2. Dynamic binding is a core concept of OOP. A language that does not
>>>> support dynamic binding does not support OOP. A program that does not
>>>> use dynamic binding is not object oriented. What is to disagree with?
>>>
>>> I don't agree with that either. You don't need polymorphism for OOP.
>>> It's
>>> quite restricted without it, but you can still program with objects even
>>> if you're restricted to something like D's structs, so you're still
>>> doing OOP.
>>>
>>> - Jonathan M Davis
>>
>> No. That is glorified procedural style. 'Objects' as in 'OOP' carry data
>> and _behavior_, structs don't (except if you give them some function
>> pointers, but that is just implementing poor man's polymorphism.)
>>
>> Having some kind of dynamic execution model is a requirement for OOP.
>> There are no two ways about it.
>
> Well, I completely disagree.  The core of OOP is encapsulating the data within
> an object

Yes, encapsulation is another core concept of OOP.

> and having functions associated with the object itself which operate
> on that data.

Correct. The functions have to be associated with _the object itself_. Case closed.

> It's about encapsulation and tying the functions to the type.

Static typing is not an OOP concept.

> Polymorphism is a nice bonus, but it's not required.

It is not a bonus. It is part of what OOP is about.

>
> I'd say that any language which is really trying to do OOP should definitely
> have polymorphism or it's going to have pretty sucky OOP, but it can still
> have OOP.
>

In case you define OOP differently from all relevant textbooks, based only on the encapsulation aspect, yes.
December 20, 2011
On 12/20/11 11:41 AM, Jonathan M Davis wrote:
> On Tuesday, December 20, 2011 17:58:30 Timon Gehr wrote:
>> On 12/20/2011 05:36 PM, Jonathan M Davis wrote:
>>> On Tuesday, December 20, 2011 15:49:34 Timon Gehr wrote:
>>>> 2. Dynamic binding is a core concept of OOP. A language that does not
>>>> support dynamic binding does not support OOP. A program that does not
>>>> use dynamic binding is not object oriented. What is to disagree with?
>>>
>>> I don't agree with that either. You don't need polymorphism for OOP.
>>> It's
>>> quite restricted without it, but you can still program with objects even
>>> if you're restricted to something like D's structs, so you're still
>>> doing OOP.
>>>
>>> - Jonathan M Davis
>>
>> No. That is glorified procedural style. 'Objects' as in 'OOP' carry data
>> and _behavior_, structs don't (except if you give them some function
>> pointers, but that is just implementing poor man's polymorphism.)
>>
>> Having some kind of dynamic execution model is a requirement for OOP.
>> There are no two ways about it.
>
> Well, I completely disagree. The core of OOP is encapsulating the data within
> an object and having functions associated with the object itself which operate
> on that data. It's about encapsulation and tying the functions to the type.
> Polymorphism is a nice bonus, but it's not required.

I think the model you're discussing is often called "object-based".

Andrei

December 20, 2011
On Sun, 18 Dec 2011 15:29:23 -0800, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> Unions will be conservative. The golden standard is that SafeD can't use
> them or anything that forces conservative approaches.
>
>
> Andrei

Is there a strong rational for a conservative approach to unions? Why not simply set the GC pointer flag bit every time a union is assigned to? Given that there are fully precise GC implementations for C, why should D aim for something less?
December 20, 2011
On Mon, 19 Dec 2011 10:54:22 -0800, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 12/19/2011 07:50 PM, Vladimir Panteleev wrote:
>> On Monday, 19 December 2011 at 08:28:52 UTC, Adam Wilson wrote:
>>> According to this wikipedia page
>>> http://en.wikipedia.org/wiki/Boehm_garbage_collector it is also the GC
>>> that is used by D, with some minor modifications of course.
>>
>> I'm not sure if that's true... I believe that they both use the same
>> basic idea, but AFAIK the D garbage collector is a D port of a C rewrite
>> which was originally written for something else. The D GC has been
>> optimized a lot since its first versions.
>
> It would probably be interesting to test the mostly concurrent
> generational Boehm GC with D. I'd expect it to perform a lot better than
> the simple mark and sweep GC we have in druntime.
>

The Boehm GC isn't concurrent nor generational.
December 20, 2011
On Sun, 18 Dec 2011 15:28:16 -0800, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 12/18/11 5:22 PM, Vladimir Panteleev wrote:
>> On Sunday, 18 December 2011 at 23:13:03 UTC, Andrei Alexandrescu wrote:
>>> On 12/18/11 4:53 PM, Vladimir Panteleev wrote:
>>>> On Sunday, 18 December 2011 at 20:32:18 UTC, Andrei Alexandrescu wrote:
>>>>> That is an interesting opportunity. At any rate, I am 100% convinced
>>>>> precise GC is the only way to go, and I think I've convinced Walter to
>>>>> a good extent as well.
>>>>
>>>> Sacrificing something (performance, executable size) for something else
>>>> is not an unilateral improvement.
>>>
>>> I think we can do a lot toward improving the footprint and performance
>>> of a precise GC while benefitting of its innate advantages.
>>
>> Still, a more conservative GC will always outperform a more precise one
>> in scanning speed.
>
> I'm not sure. I seem to recall discussions with pathological cases when
> large regions of memory were scanned for no good reason.
>

Scanning speed is proportional to the size of the live heap, which will always be larger for conservative collectors. So while conservative collectors are faster per byte, they have to scan more bytes. There's been a bunch of research into precise GCs for C, as graduate students love hard problems. There are several solutions out there currently; the one I stumbled upon is called Magpie. The associated thesis has some pretty in depth performance analyses. There are also some follow up papers from later students and more real world tests of precise vs conservative vs manual.