Array interface and environment (was Re: [Rlib-devel] Example report XML files)

[William K. V. <wk...@us...>]

Hi Bob,
On Mon, 2005-08-01 at 07:36, Bob Doan wrote:
> > I haven't had much time as things have be very busy at work however I
> > am now making pretty good progress.  The functionality is almost up
> > to the PHP interface however I've run into what I consider warts on
> > the interface.  With PHP you pretty much expect that the program
> > activate, process, and then die with every request so having a lot of
> > globals is kinda normal although that might change with PHP 5.
> > With python using globals is considered poor/lazy/hack programming.
> > The first issue, which can't be worked around if I'm going to get
> > the m.variable idiom to work, is that the "environment" needs
> > to track/store/pass a user variable to all of it's functions.
> > I need this to be able to do reference counting on python objects
> > as well as freeing temporary memory.  
> 
> I took a look at your pass rlib struct to the environment patch.  I
> don't really understand why we need to use the rlib struct.  Can't it
> just be a gpointer to something the environment mallocs then frees?

Well, since everyone is already passing the rlib struct pointer
around it seemed convenient ;-)  Using ENVIRONMENT(r) I guess
would be an option however ENVIRONMENT_PRIVATE(r) would not
be a good choice.  The problem of course is that I would just
end up storing a pointer to the rlib struct in the environment,
which seems redundant.  I need the rlib pointer as that is the
handle that I have to allow me to search through the objects
setup to track the rlib instances and local data objects.
The problem is not the single rlib report instance, it is
the multiple co-existing ones.
> 
> Other things like PHP, C can just ignore it.

As was done in the patch.

> I worry that if the environment (3rd party languages: PHP, Python, PERL,
> ect) have more direct acesss to that memory the odds of it being
> clobbered due to a programming mistake are greater.  And debugging those
> things are less then fun ;)

However the interface code already has to have access to a pointer
to the rlib structure.  Expanding that to include the environment
interface doesn't seem that onerous.  And precluding access seems
to be contrary to the point if you consider that the environment
is the environment of the rlib instance.

> > The second is with the
> > adding of the array datasource.  The add_datasource_array call just
> > says I'm going to give you one, the add_query_as passes the name
> > of the array as a string, which is then looked up in the global
> > name space.  My thought here would be to deviate from the other
> > implementations and have the add_datasource_array take a reference
> > to the array and then ignore the query string, this allows me to use
> > normal variable scope resolution so the array doesn't have to be global.
> > The problem of course is that deviations cause major confusion when
> > people are trying to port code (humm, now that I think about it I'll
> > have to look at what the C implementation does, I only looked at the
> > PHP one as that seems to be the predominant usage target).
> 
> This is a tough problem.
> 
> rlib_add_query_pointer_as already exists (Although I don't think its
> binded yet)
> 
> It's main difference is it doesn't strdup the sql pointer.  Although the
> sql pointer should not be a char * but a gpointer now that I think about
> it....
> 
> Maybe Both PHP and Python should support both ways or perhaps only
> "rlib_add_query_pointer_as".  I don't have a problem with the latter as
> it's more correct.  The reason it's global now is because I didn't know
> how to do it any better in PHP at the time due to lack of internal PHP
> documentation.

The problem with the string will always be how to resolve the scope,
by passing the reference the scoping has already been done by the
the language.  Actually I don't see how this could work in the
C interface unless your searching the programs symbol table, is that
the reason for your "should not be a char * but a gpointer now"?

Anyway I have completed an implementation of the python interface,
it works pretty much the same as the php one does now.  I did
add the rlib * to the resolve_memory_variable routine however
I've not implemented any scoping resolution (same problem of
documentation on internal operation of python).