Andrei Alexandrescu wrote:
> * "Resources come and go; memory is forever" is the likely default in D resource management. This means that destroying e.g. an array of File objects will close the underlying files, but will not deallocate the memory allocated for them. In essence, destroying values means calling the destructor but not delete-ing them (unless of course they're on the stack). This approach has a number of disadvantages, but plenty of advantages that compensate them in most applications.

I admit I'm tired right now... You mention disadvantages, the one I can't avoid thinking of is memory leak! Which means you can't write e.g. a simple web server that opens and closes files, instead of creating and managing a file object pool? Eventually it'll run out of memory, unless I'm way too tired now...

> * std.matrix will define memory layouts for a variety of popular libraries and also the common means to iterate said layouts.

I assume this is for handy and practical rectangular (and cubic, etc.) "arrays". Which would be most welcome.


This "memory is forever" philosophy, is this discussed in depth somewhere? (With the current amount of traffic here, I simply can't follow every thread anymore. :-( )

Georg Wrede wrote:
> Andrei Alexandrescu wrote:
>> * "Resources come and go; memory is forever" is the likely default in D resource management. This means that destroying e.g. an array of File objects will close the underlying files, but will not deallocate the memory allocated for them. In essence, destroying values means calling the destructor but not delete-ing them (unless of course they're on the stack). This approach has a number of disadvantages, but plenty of advantages that compensate them in most applications.
> 
> I admit I'm tired right now... You mention disadvantages, the one I can't avoid thinking of is memory leak! Which means you can't write e.g. a simple web server that opens and closes files, instead of creating and managing a file object pool? Eventually it'll run out of memory, unless I'm way too tired now...

Better said, I was too tired when I posted that. I gave too little detail. Files are resources, so they will "come and go", i.e. will be under deterministic control; there's no need to worry. Only memory will have a "lives forever" regime for safety reasons. It's not really forever as the GC collects it. In short, my proposed system is to admit that GC is good _only_ for memory, and that deterministic management must prevail for other resources. I'll get back later on this.

>> * std.matrix will define memory layouts for a variety of popular libraries and also the common means to iterate said layouts.
> 
> I assume this is for handy and practical rectangular (and cubic, etc.) "arrays". Which would be most welcome.
> 
> 
> This "memory is forever" philosophy, is this discussed in depth somewhere? (With the current amount of traffic here, I simply can't follow every thread anymore. :-( )

I decided to curb my posting as well. Beyond a point even passable content becomes just white noise. Also since we don't have an off-topic group, off-topic discussions tend to carry on here as well and are not trivial to ignore. I'm happy they are civilized (congrats to all involved).


Andrei

Andrei Alexandrescu wrote:
>>>> That way making a quick fix to broken code is just a matter of
>>>> inserting ".deprecated" into your import statements.
>>>
>>> I was thinking of moving older stuff to etc, is that ok?
>>
>> What's the rationale for "etc"? Why not "deprecated"
> 
> In the words of George Costanza: "Because it's there!"

With the critique you've given to the existing regexp stuff, deprecated would be the obvious choice.

Then we could have etc for Miscellaneous Stuff.

On Sat, Feb 21, 2009 at 2:38 AM, Georg Wrede <georg.wrede@iki.fi> wrote:
> Andrei Alexandrescu wrote:
>>>>>
>>>>> That way making a quick fix to broken code is just a matter of inserting ".deprecated" into your import statements.
>>>>
>>>> I was thinking of moving older stuff to etc, is that ok?
>>>
>>> What's the rationale for "etc"? Why not "deprecated"
>>
>> In the words of George Costanza: "Because it's there!"
>
> With the critique you've given to the existing regexp stuff, deprecated would be the obvious choice.
>
> Then we could have etc for Miscellaneous Stuff.

Agreed.
etc implies to me that it's stuff that might be useful sometimes but
not very often.
It does not suggest to me that you shouldn't use it if you can avoid it.

Or how about make it   std.etc.deprecated.regexp
That way it's clear that it's *both* something that might be useful
occasionally but something that you should avoid if possible.

... Deprecated is a keyword though, isn't it.  Dang.  :-P

--bb

Georg Wrede, el 20 de febrero a las 19:38 me escribiste:
> Andrei Alexandrescu wrote:
> >>>>That way making a quick fix to broken code is just a matter of inserting ".deprecated" into your import statements.
> >>>
> >>>I was thinking of moving older stuff to etc, is that ok?
> >>
> >>What's the rationale for "etc"? Why not "deprecated"
> >In the words of George Costanza: "Because it's there!"
> 
> With the critique you've given to the existing regexp stuff, deprecated would be the obvious choice.
> 
> Then we could have etc for Miscellaneous Stuff.

Why not "misc" for that? =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
TIGRE SE COMIO A EMPLEADO DE CIRCO: DETUVIERON A DUEÑO Y DOMADOR
	-- Crónica TV