New memory code renaming

[David Reid <dr...@jetnet.co.uk>]

Does anyone have any objections to simply calling this stuff
apr_memory_blah?

That'll give us

apr_memory_malloc
apr_memory_realloc
apr_memory_free
apr_memory_is_tracking
apr_memory_create
apr_memory_reset
apr_memory_destroy
apr_standard_memory_create
apr_tracking_memory_create
etc...

all using a type apr_memory_t

This seems to make more sense and is short enough I think.  If I don't hear
any objections I'll try to make the change over the weekend while in
Montreal.

Also, do we plan on making the plug-ins modular so they can be loaded at run
time?  Just a thought...

david

Re: New memory code renaming

[Luke Kenneth Casson Leighton <lk...@samba-tng.org>]

On Thu, May 10, 2001 at 11:54:20AM +0100, David Reid wrote:
> Why memsys???  I'm sorry I just don't follow the logic. The code deals with
> memory doesn't it?
 
semantics time:

apr_memory is a noun.  to me, it implies ownership of the memory by apr.

apr_memory_system (or memsys): implies management of memory, the
responsibility for its management.  not ownership.

okay, one reads easier than the other.  *shrug*

> Do we need to say more?

not really :)  i was just stating my personal preference: the rest
is up to you :)

> Do users really care?
 
i wouldn't know :)

> > then you can publish the API, name the .so that you wish to be loaded.
> 
> OK, but it's a long way aways yet anyway...

yep.

Re: New memory code renaming

[Ben Laurie <be...@algroup.co.uk>]

David Reid wrote:
> 
> Why memsys???  I'm sorry I just don't follow the logic. The code deals with
> memory doesn't it?
> 
> > On Thu, May 10, 2001 at 01:54:51AM +0100, David Reid wrote:
> > > Does anyone have any objections to simply calling this stuff
> > > apr_memory_blah?
> > >
> > > That'll give us
> > >
> > > apr_memory_malloc
> > > apr_memory_realloc
> > > apr_memory_free
> > > apr_memory_is_tracking
> > > apr_memory_create
> > > apr_memory_reset
> > > apr_memory_destroy
> > > apr_standard_memory_create
> > > apr_tracking_memory_create
> > > etc...
> >
> > prefer memsys, it says more.
> 
> Do we need to say more?  Do users really care?

Users may not care, but programmers do :-)

The only reason I care is that it doesn't make sense to me to use a word
for something that so many other things could equally well use - so my
vote would be for sms :-)

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Re: New memory code renaming

[David Reid <dr...@jetnet.co.uk>]

Why memsys???  I'm sorry I just don't follow the logic. The code deals with
memory doesn't it?

> On Thu, May 10, 2001 at 01:54:51AM +0100, David Reid wrote:
> > Does anyone have any objections to simply calling this stuff
> > apr_memory_blah?
> >
> > That'll give us
> >
> > apr_memory_malloc
> > apr_memory_realloc
> > apr_memory_free
> > apr_memory_is_tracking
> > apr_memory_create
> > apr_memory_reset
> > apr_memory_destroy
> > apr_standard_memory_create
> > apr_tracking_memory_create
> > etc...
>
> prefer memsys, it says more.

Do we need to say more?  Do users really care?

>
> > This seems to make more sense and is short enough I think.  If I don't
hear
> > any objections I'll try to make the change over the weekend while in
> > Montreal.
> >
> > Also, do we plan on making the plug-ins modular so they can be loaded at
run
> > time?  Just a thought...
>
> yes, that was part of a plan, too.
>
> then you can publish the API, name the .so that you wish to be loaded.

OK, but it's a long way aways yet anyway...

david

Re: New memory code renaming

[Luke Kenneth Casson Leighton <lk...@samba-tng.org>]

On Thu, May 10, 2001 at 01:54:51AM +0100, David Reid wrote:
> Does anyone have any objections to simply calling this stuff
> apr_memory_blah?
> 
> That'll give us
> 
> apr_memory_malloc
> apr_memory_realloc
> apr_memory_free
> apr_memory_is_tracking
> apr_memory_create
> apr_memory_reset
> apr_memory_destroy
> apr_standard_memory_create
> apr_tracking_memory_create
> etc...
 
prefer memsys, it says more.

> This seems to make more sense and is short enough I think.  If I don't hear
> any objections I'll try to make the change over the weekend while in
> Montreal.
> 
> Also, do we plan on making the plug-ins modular so they can be loaded at run
> time?  Just a thought...

yes, that was part of a plan, too.

then you can publish the API, name the .so that you wish to be loaded.

the only tricky bit about that is that separate memsyses will have
different initialisation routines, and i'm not so sure it's a good
idea to use varargs on a .so, for that! :)

heck, it's just a typecast, anyway.  ah well.