Move scoped_temp_dir and scoped_native_library back from base/memory to base.

Move scoped_temp_dir and scoped_native_library back from base/memory to base.

It looks like they got moved accidentally in http://codereview.chromium.org/6714032

BUG=none
TEST=none

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=86010

[Nico, 2011-05-19 19:07:10]

All the include file munging was done by tools/git/mass-rename.sh and
tools/reorder-includes.py

[brettw, 2011-05-19 19:13:14]

Rubber stamp LGTM

[levin, 2011-05-19 19:15:14]

Seems like scoped_native_library is in keeping with the theme of base/memory
(scoped_nsobject, scoped_open_process).

However, scoped_temp_dir doesn't belong there.

[brettw, 2011-05-19 19:16:16]

I don't think scoped_native_library belongs in memory. Maybe best would be
base/files, but I'm also OK with this patch.

[levin, 2011-05-19 19:21:51]

On 2011/05/19 19:16:16, brettw wrote:
> I don't think scoped_native_library belongs in memory. Maybe best would be
> base/files, but I'm also OK with this patch.

I'm not sure why scoped_native_library would be in files.  It is about freeing a
loaded library. Why do this except for memory concerns? (If I had garbage
collection, I wouldn't do this.)

Also, does scoped_open_process belong in base/memory if
base/scoped_native_library doesn't?

[Nico, 2011-05-19 19:22:40]

On Thu, May 19, 2011 at 12:15 PM,  <levin@chromium.org> wrote:
> Seems like scoped_native_library is in keeping with the theme of base/memory
> (scoped_nsobject,

scoped_nsobject is the ObjC equivalent of scoped_ptr and is about
managing memory.

> scoped_open_process).

I didn't see that, else I would've moved that too. I don't think that
belongs in base/memory either.

>
> However, scoped_temp_dir doesn't belong there.
>
>
> http://codereview.chromium.org/7048007/
>

[commit-bot: I haz the power, 2011-05-19 19:26:12]

Can't process patch for file base/scoped_native_library.cc.
A +

[levin, 2011-05-19 20:12:34]

On 2011/05/19 19:22:40, Nico wrote:
> On Thu, May 19, 2011 at 12:15 PM,  <mailto:levin@chromium.org> wrote:
> > Seems like scoped_native_library is in keeping with the theme of base/memory
> > (scoped_nsobject,
> 
> scoped_nsobject is the ObjC equivalent of scoped_ptr and is about
> managing memory.
> 
> > scoped_open_process).
> 
> I didn't see that, else I would've moved that too. I don't think that
> belongs in base/memory either.

I think it is helpful to come up with a definition of what something is, so that
one can know what it is about. Here's my attempt: base/memory is a directory
that holds files related to memory management include utilities one wouldn't
need if you were using a garbage collected language.

What's your definition (brettw/thakis)?

[Nico, 2011-05-19 20:16:43]

On Thu, May 19, 2011 at 1:12 PM,  <levin@chromium.org> wrote:
> On 2011/05/19 19:22:40, Nico wrote:
>>
>> On Thu, May 19, 2011 at 12:15 PM,  <mailto:levin@chromium.org> wrote:
>> > Seems like scoped_native_library is in keeping with the theme of
>> > base/memory
>> > (scoped_nsobject,
>
>> scoped_nsobject is the ObjC equivalent of scoped_ptr and is about
>> managing memory.
>
>> > scoped_open_process).
>
>> I didn't see that, else I would've moved that too. I don't think that
>> belongs in base/memory either.
>
> I think it is helpful to come up with a definition of what something is, so
> that
> one can know what it is about. Here's my attempt: base/memory is a directory
> that holds files related to memory management include utilities one wouldn't
> need if you were using a garbage collected language.
>
> What's your definition (brettw/thakis)?

This sounds like a fine definition. I disagree that library loading /
unloading wouldn't be done explicitly in a garbage collected language:
In Java, you're e.g. not supposed to rely on finalizers for freeing
things like files, large bitmaps backed by native memory, etc. All
these have explicit close() / recycle() etc calls. A loaded library is
likewise more heavyweight than normal memory handling.

>
>
>
>
> http://codereview.chromium.org/7048007/
>

[levin, 2011-05-19 20:18:44]

On 2011/05/19 20:16:43, Nico wrote:
> 
>  I disagree that library loading /
> unloading wouldn't be done explicitly in a garbage collected language:
> In Java, you're e.g. not supposed to rely on finalizers for freeing
> things like files, large bitmaps backed by native memory, etc. All
> these have explicit close() / recycle() etc calls. A loaded library is
> likewise more heavyweight than normal memory handling.
> 
Sounds reasonable. Thanks for the discussion. Sorry for putting this in a bad
place :)