At 05:58 PM 6/10/2001 -0400, Sam Tregar wrote:
>SQL via DBI. It's got a terrible learning curve but it's still around for
>a reason. You learn all about SQL's strengths if you start trying to
>replace it with arrays and hashes. Go forth and learn!
He's right. I do a lot of DBI stuff with Oracle, and every so often I have
a hankering for some kind of structured tied variable that would look like
my database. Then I wake up and realize that modeling of a single table
doesn't do squat for me, and modeling of the whole database requires
knowledge of the foreign key relationships, and even with those, no
variable structure suggests itself. And then I remember this is why I
wrote object classes modeling the things I want to get out of/put into the
database.
Even if your database is so simple that you do just want to model single
tables, it would be easy to build atop DBI.
<DejaVu>Didn't we have this discussion about six months ago???</>
I do think it's worth thinking about new variable types for Perl. I keep
thinking to myself, how do we continue the progression C -> Perl 4/5 ->
..., where Perl 4/5 said things like, let's make hashes basic variable
types, since they're so mind-bogglingly useful. Not that you couldn't do
them in C with library functions, but look how much easier they are to
read. So I think, what's the next step? But I just keep drawing a blank.
Once I spent some time wondering about design patterns and templates, but
that didn't lead anywhere either.
The thing I don't want to happen is for all the work to go into O-O
features, because at the end of the day, all O-O programs look much the
same: instantiate a bunch of objects and call methods on them. Then it
seems like the only thing left to talk about is whether you use -> or . for
component separators. I want Perl to make it easy to implement algorithms,
rather than just trying to compete on the same playing field as other O-O
languages, because it's just too handicapped by things like performance and
lack of static analysis.
