D 2015/2016 Vision?

[Paulo Pinto 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:
>> On Tuesday, 6 October 2015 at 18:10:42 UTC, bitwise wrote:
>>> On Tuesday, 6 October 2015 at 17:20:39 UTC, Jonathan M Davis 
>>> wrote:
>>> I'm not sure what else I can say. The example I posted says 
>>> it all, and it can't be done properly in D (or C#, but why 
>>> lower the bar because of their mistakes? ;)
>>
>> 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.
>
> You are literally repeating what I just said in different words.
>
>> 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.
>
> This is an opinion.
>
> I want polymorphism AND deterministic destruction, and the 
> least you could do is just admit that it's a downside to D not 
> having it, instead of trying to tell me that everything I know 
> is wrong..
>
>> But in the cases where you do have to use a class, it can get 
>> annoying.
>
> YES, its does, and it's not just an odd case here and there..
>
>> 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.
>
> I'm sorry, but I almost can't believe you're saying this.
>
> So, you're saying you want me to just revert back to manual 
> resource management and accept that huge resources like 
> textures and such may just leak if someone doesn't use them 
> right? or throws an exception? in a language like D that is 
> supposed to be safe?
>
>> 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
>
> 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) {
>     // ...
> }
>

That no, but this yes (at least in C#):

using (LevelManager mgr = new LevelManager())
{
      //....
      // Somewhere in the call stack
      Texture text = mgr.getTexture();
}
--> All level resources gone that require manual management gone
--> Ask the GC to collect the remaining memory right now

If not level wide, than maybe scene/section wide.

However I do get that not all architectures are amendable to be 
re-written in a GC friendly way.

But the approach is similar to RAII in C++, reduce new to minimum 
and allocate via factory functions that work together with handle 
manager classes.

--
Paulo