Re: 3.0.10

On Jun 20, Manuel Lemos wrote: > >abstraction layer. I'm just pointing out that some of the lessons > >learned on these other tasks can be applied to that task. > > What kinds of lessons? I don't know. How to build an abstraction on top of differing implementations of similar interfaces? How to reduce the amount of clutter the abstraction introduces? To just implement it and let people discover after the fact how cool it is, like Sascha did with the dbm abstraction layer? > Right, but it is important to keep the doors open for the layer to evolve > to cover for important needs even if is not possible to have support in all > kinds of RDBMS. Of course. I didn't intend to say otherwise. > It seems that a lot of people only care for MySQL. If MySQL does not > support something, it is not worthy to support for other drivers. I think > that it is a mistake. I agree. I didn't intend to imply otherwise. > Implementing something to not be used later because the developer decided > to do his own way ignoring potential design mistakes that other could have > brought to the attention, IMHO is a worse waste of time. My point is that I would rather that people make mistakes rather than just talk about making them or avoiding them. Every time the abstract database layer comes up, all that ever comes out of it is a lot of hot air (and I'm certainly not helping matters this time, either). I could rant about how much I dislike DBI, or how I think that making the abstraction layer be object-oriented is a mistake, but I don't want to temper the enthusiasm of anyone willing to do the work. I could be wrong. I could be right, but they may solve any number of important issues in coding up their implementation. I don't want to draw too many lines around the problem or people may get the impression that they aren't allowed to color outside of them. Jim