D 2015/2016 Vision?

[Paulo Pinto via Digitalmars-d]

On Tuesday, 6 October 2015 at 18:43:42 UTC, Jonathan M Davis 
wrote:
> On Tuesday, 6 October 2015 at 18:10:42 UTC, bitwise wrote:
>> [...]
>
> It's a side effect of having the lifetime of an object managed 
> by the GC. There's no way around that except to use something 
> else like manual memory management or reference counting. In D, 
> it's a good reason to use structs to manage resources like 
> that, and since most objects really have no need of inheritance 
> and have no business being classes, it's usually fine. But in 
> the cases where you do have to use a class, it can get annoying.
>
>> [...]
>
> You simply do not rely on the GC or the destruction of the 
> object to free system resources. You manually call a function 
> on the object to free those resources when you're done with it. 
> In the case of C#, they have a construct to help with it that 
> (IIRC) is something like
>
> using(myObj)
> {
> } // myObj.dispose() is called when exiting this scope
>
> In Java, you'd have no choice but to call dispose manually. And 
> yes, that sucks, but it's life with a GC-managed object. The GC 
> has a number of benefits to it, but it does not come without 
> its costs.
>
> Having the option to have properly ref-counted classes in 
> addition to classes managed by the GC would definitely be an 
> improvement, and I expect that we'll get there at some point, 
> but there _are_ ways to deal with the problem in the interim, 
> even if it's not ideal.
>
> In most cases though, just don't use classes. In most cases, 
> inheritance is a horrible way to write programs anyway, because 
> it's _horrible_ for code reuse. It definitely has its uses, but 
> I've found that I rarely need classes in D. 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.
>
> - Jonathan M Davis

As of Java 7

     try (BufferedReader br =
                    new BufferedReader(new FileReader(path))) {
         return br.readLine();
     }


Or just use a functional programming pattern for resource 
management:

withFile (something, { fd -> work with file })

Better languages allow to write that like

withFile (something) { fd -> work with file }

GC is not an hindrance when the languages are built to properly 
work with it.

--
Paulo