On Fri, Jan 30, 2004 at 02:26:27PM +0000, Harry Jackson wrote:
dbstring = "host=lhost dbname=name user=user password=pass"
.pcc_begin prototyped
.arg dbstring .pcc_call connect retconnect:
.result dbh
.pcc_end
print "New $dbh successful????\n"
When we move to objects we'll add in the driver handle and call connect as a method on that.
The actual connect call above is the DBDI call which then calls the connect function on the driver.
Nooo. Ultimately it should be a method call on a dbr object which will be blessed into DBD::<foo>::dr (the driver class).
There should be no "DBDI" intercepting calls up front (as far as possible), only providing default methods in the base classes.
(I appreciate you're having to hack around the lack of method calls so maybe that's why you're going that way, but it's not ideal.)
So far I have been unable to come up with a way that we can make the API even resemble objects and methods hence the reason why I was playing with containers ie a dbh container holds all its functions calls and statement handles which then hold their function calls etc. This is not ideal and will lead to lots of contortions but does offer some privacy.
I would like to put each arg in an array and pass that in rather than having a massive arg list or would you rather have them all seperate.
Separate, "as per the DBI spec".
Looking at the DBI spec we have
$dbh = DBI->connect($data_source, $username, $auth, \%attr);
Looking at the DBD spec we have
$dbh = connect($dbname, $user, $auth, $attr);
(In Perl) Being objects they also pass themselves around as the first arg so the _Function_ (not method) call on a drh _PMC_ (not object) to connect in parrot would look like
.pcc_begin prototyped .arg drh # PMC .arg data_source # string .arg username # string .arg auth # string .arg attr # PerlHash .pcc_call connect retconnect: .result dbh # PMC .pcc_end
This returns a dbh. This is one of the areas where I was thinking about using containers. The dbh holds the PMC that gets returned from the driver call. It will also hold all the associated _Function_ calls that are allowed to be called on that PMC. I am still very much experimenting with how to make the API resemble objects, this is probably a lost cause (please see the bottom of the email)
Is that returning a new PerlArray each time? I think that should be another reference and have fetch() return a reference to the same (internal) PerlArray each time.
It is buried in the driver somewhere so I will need to dig to find out. If it is it should be easy to fix. Would you prefer to have the array passed in as a parameter. This means we can create it before the loop and reuse it.
No, "as per the DBI spec" "as per the DBI spec" "as per the DBI spec" :) fetch() is a method on the sth that takes no params and returns an array ref. Period.
Tim. When I say buried in the Driver I really mean buried in the driver. I know it needs to come out but we do not have objects yet. I can make it a global which seems reasonable or I can pass it in as an argument but without objects I am unable to make it a member variable. We can mimick it if we use some sort of container ie
.sym PerlArray arr sth['array_ref'] = arr
This could be done before the sth gets passed back from the _Function_ call to prepare.
Objects, We don't have then _yet_ which means, as well as trying to
impliment a standard we are trying to come up with an API that will
change very little when we do. This has meant that I am playing with
various methods to make it look like we are using objects when in fact
the backend is a hodge podge of function calls and global abuse on a galactic scale.
The closest thing I can some up with at the moment without going to name mangling is a container which holds its _Function_ calls and any object calls that are required of it. They also hold any subclassed objects which then contain _their_ function calls etc etc.
Question: Since Dan has said that objects are nearly finished is there any point spending too much time working on this. Would our time be better spent helping to get objects finished pronto.
Harry
