D 2015/2016 Vision?

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 6 October 2015 at 20:43:42 UTC, bitwise wrote:
> On Tuesday, 6 October 2015 at 18:43:42 UTC, Jonathan M Davis 
> wrote:
> For the THIRD time, I'll post my example:
>
> class Texture { }
> class Texture2D : Texture {
>     this() { /* load texture... */ }
>     ~this { /* free texture */ }     // OOPS, when, if ever, 
> will this be called?
> }
>
> Now, does this really seem like a realistic use case to you?
>
> using(Texture tex = new Texture2D) {
>     // ...
> }

The reality of the matter is that having the lifetime of an 
object managed by a GC inherently does not work with 
deterministic destruction. Garbage collectors simply do not work 
that way. It's a cost to using them. Code like this is what you 
have to do when you have a garbage collected language without the 
ability to put objects on the stack. C# and Java and their ilk 
are stuck with that. And it definitely sucks, but it can work.

In D, if you're using only classes, you're still stuck with that. 
However, if you use structs to wrap classes and do reference 
counting, then it becomes possible to have deterministic 
destruction for classes, because the struct is doing the 
deterministic part, and the lifetime of the class object is no 
longer managed by the GC (assuming that you don't end up with 
something like the last of the structs with references to that 
class object inside of classes which aren't ref-counted, in which 
case, you lost the deterministic destruction and the GC manages 
the lifetime again). So, we're doing better than C# or Java do, 
but unfortunately, there are just enough issues with ref-counting 
structs that to get it fully right, we do need ref-counting in 
the language (unfortunately, I don't remember all of the corner 
cases that make that the case). So, ref-counting with structs 
_mostly_ works, and it is a solution, but it's not quite where we 
want it to be, which is Walter and Andrei have been talking about 
adding ref-counting support to the language and DIP 74 was 
proposed.

> _Is_ it just the interim? Will DIP74 actually ever be 
> implemented? if so, when?

We don't know. It hasn't been officially accepted yet. Walter and 
Andrei could change their minds and decide that it's not 
necessary to add ref-counting support to the language. It could 
be that DIP 74 or something like it ends up being accepted and 
implemented in a year or three. Or it could be accepted as-is 
tomorrow. Until Walter and Andrei make a decision on it, we don't 
know. Given the issues involved, I expect that some form of DIP 
74 will be accepted at some point in the future, but they're not 
going to do that until they're reasonably sure that we've got it 
right, and that sort of thing is always slow. So, we may very 
well end up with ref-counting in the language sometime next year, 
but I'd be shocked if it were this year, and depending on what 
Walter and Andrei are focusing on, it could be longer than that.

>> In most cases though, just don't use classes. In most cases, 
>> inheritance is a horrible way to write programs anyway,
>
> Opinion.

It's well known that it's generally better to use composition 
than inheritance. Inheritance is useful when you need to have 
runtime polymorphism - where multiple types need to be used in 
exactly the same code as if they were the same type with the code 
using them not caring what they really are. Beyond that, it just 
starts causing problems - especially with regards to reusibility. 
As soon as code is in a member function, the only way it can be 
reused is by deriving from the class that it's in, which is 
incredibly limiting. Free functions (especially templated free 
functions) cream member functions for flexibility and 
reusibility, because they aren't restricted to a single type and 
its descendants. This is especially true when the language does 
not support multiple inheritance.

Inheritance makes sense when it's needed, but when you use it, 
you're losing flexibility and harming code reusibility, meaning 
that if it's not actually needed, it's just costing you. And I 
don't see how anyone can really argue otherwise.

Where a lot of that gets debatable is when deciding whether a 
particular problem actually needs a solution that uses 
polymorphism, but it's quite clear that using inheritance limits 
code reusibility.

>> I suspect that far too many folks new to D end up using 
>> classes instead of structs just because they're used to
>> using classes in C++ or Java or whatever.
>
> I use classes for polymorphism, and although I can't speak for 
> everyone else, I doubt I'm the only one.

And that's what D classes should be used for. But based on 
questions on SO and stuff in D.Learn and other places online, 
it's pretty clear that at minimum, many folks that are new to D 
use classes even when they don't need polymorphism.

- Jonathan M Davis