Non-OO interface to mysql

[Lars Eighner]

Just another in a series of periodic requests asking if anyone has run
across a non-OO interface to MySQL.

 

[sln]

Just another in a series of periodic requests asking if anyone has run
across a non-OO interface to MySQL.

Are you looking for one?

sln

 

[Tim Greer]

Just another in a series of periodic requests asking if anyone has run
across a non-OO interface to MySQL.

I don't know of any off hand, but I'm assuming there could be something
out there, or you could write your own method. However, I don't see a
reason to seek such a thing out, just to avoid OO (so I assume there's
more to the question), and that could be a pretty big wheel to
reinvent, especially with all of the error checking, etc. Is there
more to the issue than that (being OO or not)? If so, you might get a
more suitable suggestion than just a non OO solution.

 

[Lars Eighner]

In our last episode,
the lovely and talented Tim Greer
broadcast on comp.lang.perl.misc:

Lars Eighner wrote:

I don't know of any off hand, but I'm assuming there could be something
out there, or you could write your own method.

Err...no. The idea is to avoid methods.

However, I don't see a reason to seek such a thing out, just to avoid OO
(so I assume there's more to the question),

The idea is precisely to avoid OO (best) or at least to have function type
calls (second best).

The problem is PHP has function-type (or function looking) mysql interface,
but sucks for string and text manipulation in general. Perl has good text
and string manipulation, but has DBI objects (and even the Mysql.pm is now
really just an alias for the DBI objects, with method-type calls.

and that could be a pretty big wheel to
reinvent,

precisely why I keep hoping to find it has been done.

especially with all of the error checking, etc. Is there more to the
issue than that (being OO or not)?

Nope, that's it: avoiding OO so far as possible and OO type calls even if
OO behind the scenes cannot be avoided.

 

[sln]

Just another in a series of periodic requests asking if anyone has run
across

I'm sure you could program somethin like ADO.
But It sounds like your interested in biting your nuts off.

sln

 

[Lars Eighner]

In our last episode,
the lovely and talented (e-mail address removed)
broadcast on comp.lang.perl.misc:

I'm sure you could program somethin like ADO.

Alternate Dimension Overhead?
Alien Dominated Orchids?
Anodized Dominican Organization?

What?

Surely the O could not stand for 'Object' since the idea is not to use
objects.

But It sounds like your interested in biting your nuts off.

Whatever that means.

 

[skeldoy]

Just another in a series of periodic requests asking if anyone has run
across a non-OO interface to MySQL.

You could always create a security nightmare/spaghetti-nest by
invoking the mysql-tool from backticks..
`mysql -u root database -e "select * from table;"` or something to
that accord.

Still. Not really sure why one would do such a thing. Gonna side with
the "biting of the nuts"-man there.

 

[Lars Eighner]

In our last episode,

You could always create a security nightmare/spaghetti-nest by
invoking the mysql-tool from backticks..
`mysql -u root database -e "select * from table;"` or something to
that accord.

Well, yes, that's how I will go if I have to build it myself. What I asking
is if the functions for parsing the return already exist somewhere.

 

[Peter J. Holzer]

In our last episode,



Well, yes, that's how I will go if I have to build it myself. What I asking
is if the functions for parsing the return already exist somewhere.

Oh my god. That's really the worst way to implement it.

Write simple wrapping functions around DBI, if you prefer to write
$rows = mysql_selectall_arrayref($dbh, "select * from table");
instead of
$rows = $dbh->selectall_arrayref("select * from table");

Or write wrapper functions around the C API if you prefer writing XS to
writing Perl (but then, why would you write in Perl in the first case?).

But parsing the output of mysql is just plainly insane.

hp

 

[Peter J. Holzer]

As someone else posted, you could simply write your own function-style
wrappers around the DBI methods. Compared to basically rewriting DBI in
a functional style from scratch,

Rewriting DBI in a functional style might be interesting (SQL already
has some properties of functional languages). But Lars doesn't strike me
as a Lisp or Haskell fan.

hp

 

[Lars Eighner]

What exactly do you hope to gain by avoiding OO?

1) The horrible slowness and waste of resources.
2) Little ASCII art pictures of arrows in code (especially where the arrows
point the counterintuitive way)

 

[Uri Guttman]

LE> 1) The horrible slowness and waste of resources.

you don't know how fast it is until you compare it. premature
optimization and all. the DB itself is way slower than any OO perl code
you would use. this is a very silly (which means stupid) argument
defending your point.

also programmer time is way more expensive than cpu time. do you want to
waste all your hours developing this thing or just buy a faster cpu?

LE> 2) Little ASCII art pictures of arrows in code (especially where
LE> the arrows point the counterintuitive way)

just turn your head around and the arrows point in the right way. you
have a strange view of coding if that is what really bothers you. don't
go near c or pl1 which had that arrow style for decades.

that makes less and less sense. what if mysql was written in c++ or uses
some c++? would you avoid it? you have an irrational fear like any other
phobia. it is all in your mind and not in the code.

that being said, OO isn't for every problem but a blanket refusal of all
OO especially for your silly reasons means you aren't a good
programmer. OO is a useful tool but like any tool can be
abused. ignoring OO is just abusing yourself.

uri

 

[Tim Greer]

Lars Eighner wrote:

1) The horrible slowness and waste of resources.

I know there are certain people that act like OO is going to kill
efficiency, but it will not. There is good OO code and bad non OO
code. The more important aspect is database design. The modules now
are absolutely not going to impose a problem. You could spend a very
long time trying to create an alternative and it still might not be any
faster.

Either way, to have all of the maturity, checking, etc. that the current
modules do, it's going to take a lot longer to develop an alternative
just to not be OO, then it would to just use OO and move onto more
interesting things. If you wish to, by all means, there's nothing
wrong with creating a non OO interface, but I don't think it's
legitimate. It's not horribly slow and it doesn't waste resources. If
you're concerned with speed, why not use C? Why use Perl at all?

2) Little ASCII art pictures of arrows in code (especially where the
arrows point the counterintuitive way)

If you were willing to work with OO code in Perl, it would probably take
only a few hours (though maybe days or weeks, depending on the time you
have and interest, as well as the goal) to get really good at it.

Again, if you want to do it, go for it. I don't see this as a
legitimate debate though. You could probably make something faster
that's non OO, but I doubt that OO is that big of an aspect in this
case and all that work for just avoiding OO seems like the wasted
resources.

 

[Lars Eighner]

In our last episode,
the lovely and talented Uri Guttman
broadcast on comp.lang.perl.misc:

LE> In our last episode, <[email protected]>, the
LE> lovely and talented Keith Keller broadcast on comp.lang.perl.misc:

LE> 1) The horrible slowness and waste of resources.

you don't know how fast it is until you compare it. premature
optimization and all. the DB itself is way slower than any OO perl code
you would use. this is a very silly (which means stupid) argument
defending your point.

also programmer time is way more expensive than cpu time. do you want to
waste all your hours developing this thing or just buy a faster cpu?

LE> 2) Little ASCII art pictures of arrows in code (especially where
LE> the arrows point the counterintuitive way)

just turn your head around and the arrows point in the right way. you
have a strange view of coding if that is what really bothers you. don't
go near c

I think you mean c++, not the same thing as c.

or pl1 which had that arrow style for decades.

that makes less and less sense. what if mysql was written in c++ or uses
some c++? would you avoid it? you have an irrational fear like any other
phobia. it is all in your mind and not in the code.

 

[Uri Guttman]

LE> I think you mean c++, not the same thing as c.

and that is your useful comment to my post? begone with ye and code no
more.

btw, i have done procedural code in many langs as well as OO style code
in assembler and C. i have wrapped OO modules in perl into procedural
things and there is even a module out there that can do that for you.

basically it comes down to you unsupportable fears. if you want help
with perl coding, ask it here. to conquer you fears, seek therapy.

uri

 

[Charlton Wilbur]

LE> In our last episode, <[email protected]>, the
LE> lovely and talented Uri Guttman broadcast on
LE> comp.lang.perl.misc:


LE> 2) Little ASCII art pictures of arrows in code (especially where
LE> the arrows point the counterintuitive way)

LE> I think you mean c++, not the same thing as c.

You are aware that the -> operator comes from C, no?

foo->bar is syntactic sugar for (*foo).bar.

Charlton

 

[Peter J. Holzer]

1) The horrible slowness and waste of resources.

If you care about that, why are you coding in Perl? Compared to any
language that compiles to native code (even indirectly via a
JIT-compiler, like most Java implementations) it's horribly slow. And
compared to any language which uses an explicit type system, it's a
horrible waste of computer resources. (But it frees a lot of human
resources, and for a given time budget, the Perl programmer may even be
able to write a faster and less resource-intensive program than the C
programmer).

Now, let's do a little reality check on the "horrible slowness":


#!/usr/bin/perl
use warnings;
use strict;

use Benchmark 'cmpthese';

my $phandle = 23;
my $ohandle = MyClass->new();
my $arg = "this is an argument";

cmpthese(-3,
{
'proc' => sub { foo($phandle, $arg) },
'oo' => sub { $ohandle->foo($arg) },
});


sub foo {
my ($handle, $arg) = @_;
return $arg;
}


package MyClass;

sub new {
my ($class) = @_;
my $self = {};
return bless $self, $class;
}

sub foo {
my ($self, $arg) = @_;
return $arg;
}
__END__

This little program compares a "procedural" subroutine call with an
oo-style method call.

Rate oo proc
oo 783445/s -- -7%
proc 838852/s 7% --

Hooray, procedural calls are 7 percent faster. That's a whopping 84
nanoseconds per call. But let's run it again:

Rate proc oo
proc 786957/s -- -7%
oo 842802/s 7% --

Oh, this time oo is 7 percent faster.

If you repeat that a few times you will see that in about 50 % of the
cases the procedural call is slightly faster than the oo call and in
50 % of the cases the oo call is slightly faster - or in other words,
the difference is not even measurable with a simple benchmark.

hp

 

[Klaus]

Oh my god. That's really the worst way to implement it.

Write simple wrapping functions around DBI, if you prefer to write
    $rows = mysql_selectall_arrayref($dbh, "select * from table");
instead of
    $rows = $dbh->selectall_arrayref("select * from table");

No need to write wrapper functions. A plain...

$rows = DBI::mysql_selectall_arrayref($dbh, "select * from
table");

....should work.

 

[Peter J. Holzer]

On Dec 21, 8:53 pm, "Peter J. Holzer" <[email protected]> wrote:

[Non-OO DB interface]

No need to write wrapper functions. A plain...

$rows = DBI::mysql_selectall_arrayref($dbh, "select * from
table");

...should work.

No, because $dbh is not an object of the class DBI, but of the class
DBI::db.
DBI uses quite a lot of classes internally, and several of them depend
on the DBD driver actually in use, so you generally don't know (and
shouldn't care) which class an object belongs to (just which interface
it implements, to borrow some terminology from Java).

hp

 

[C.DeRykus]

...
#!/usr/bin/perl
use warnings;
use strict;

use Benchmark 'cmpthese';

my $phandle = 23;
my $ohandle = MyClass->new();
my $arg = "this is an argument";

cmpthese(-3,
{
'proc' => sub { foo($phandle, $arg) },
'oo' => sub { $ohandle->foo($arg) },
});

sub foo {
my ($handle, $arg) = @_;
return $arg;

}

package MyClass;

sub new {
my ($class) = @_;
my $self = {};
return bless $self, $class;

}

sub foo {
my ($self, $arg) = @_;
return $arg;}

__END__

This little program compares a "procedural" subroutine call with an
oo-style method call.

Rate oo proc
oo 783445/s -- -7%
proc 838852/s 7% --

Hooray, procedural calls are 7 percent faster. That's a whopping 84
nanoseconds per call. But let's run it again:

Rate proc oo
proc 786957/s -- -7%
oo 842802/s 7% --

Oh, this time oo is 7 percent faster.

If you repeat that a few times you will see that in about 50 % of the
cases the procedural call is slightly faster than the oo call and in
50 % of the cases the oo call is slightly faster - or in other words,
the difference is not even measurable with a simple benchmark.

Totally agree but this particular code gives OO an
edge due to method caching.

A slight tweak: $arg . ("a".."z")[int(rand(26))]
consistently tilts for the faster procedural call ...
at least for some small Solaris and Linux sample
runs.