Nadim, in both this and a previous posts, has asked the very valid
question of "Why bother? We already have DBI for this." I'd like to try
to address his point.
On Fri, 1 Mar 2002, Nadim Khemir wrote:
> 2/ If someone wants to write Inline::InternetExplorer, I don't care, if that
> someone wants to make things more complicated to the user by hiding easy
> perl code behind an extra layer fine, it that someone still wants to add
> useless modules to CPAN fine this is a free world. Now, why make things more
> complicated than they need? Isn't a perl sub calling DBI as clear and
> effective?
As effective: Yes, and probably more so, in terms of efficiency. And 99%
of the time, just as clear as well. There are times however, when I end
up writing code that isn't actually very clear:
my @ids = 1..3;
if (shift @{shift @{$dbh->selectall_arrayref(qq{ select count(*) from users where id
in ( @{[ join(", ", @ids) ]} ) })} }) {
# I know at least some of these ids are real ...
} else {
# none of these are good ids ...
}
So sure, I could do this instead:
my @ids = 1..3;
if (count_ids(@ids)) {
#
} ...
sub count_ids {
return shift @{ shift @{$dbh->selectall_arrayref(qq{ select count(*) from users
where id in ( @{[ join(", ", @_) ]} ) })} };
}
But what I'd really like to do is:
if (count_ids(@ids)) {
#
} ...
__SQL__
SCALAR count_ids(@ids) {
select count(*) from users where id in ( @ids );
}
And let Inline::SQL (or whatever it's called) do all the binding and
whatnot. I think this is much cleaner than the equivalent "inlined DBI
code".
-Aaron
>
> 3/ I have the impression that people want to use Inline as the Filter module
>
> 4/ I agree about most Patrick write, but abstraction is _not_ always good.
> We are mechanics, except that our bolts are made of bits and our machines
> are compilers.
>
> If a Inline::SQL is to be seen some day that's fine go and write it. But
> meanwhile take the remarks from this mailing list as help from a friend
> (even if friends are some times tiresome) just make it so good so I can use
> it ;-)
>
> Nadim.
>
> > -----Original Message-----
> > From: Patrick LeBoutillier [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, March 01, 2002 3:20 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Fw: Inline::SQL
> >
> > Hi,
> >
> > > There has been quite a bit of followup to my first posted ramblings;
> > I've
> > > recieved lots of ideas, most of them very good. Fundamentally, though,
> > > there's the idea that this isn't really an "Inline" package, as in
> > > "(pre)compile this bit of native language in some other language-space
> > and
> > > then make it available to my perl script". It's more of a
> > "automatically
> > > build perl subroutines for me that make use of DBI". So maybe it's more
> > > of a DBIx::Inline::SQL or somesuch.
> >
> > The first line of the Inline docs states this:
> >
> > Inline - Write Perl subroutines in other programming
> > languages.
> >
> > Although it can be argued whether or not SQL is a programming language, I
> > think
> > that using this definition your module could very much use the Inline
> > namespace.
> > Personnally that's how I see Inline. For me the "inlining" (and the
> > resulting abstraction)
> > is what it is all about.
> >
> > I don't think what it is you are inlining should be relevant to using the
> > Inline namespace.
> > The fact of encapsulating something, automatically creating perl subs to
> > use
> > that
> > something and make it easy for the user is enough for me. But that's just
> > my
> > opinion.
> >
> > But I think it's an interesting debate...
> >
> > Cheers,
> >
> > Patrick
> >
> >
>
>
--
Aaron J Mackey
Pearson Laboratory
University of Virginia
(434) 924-2821
[EMAIL PROTECTED]
