From: Ian B. <ia...@co...> - 2003-11-11 17:14:49
|
On Nov 11, 2003, at 4:20 AM, John Baker wrote: > If SQLObject is to be aimed at a very limited set of solutions, that > don't > lend themselves towards proper OO programming, then perhaps clearly > stating this on the website would be a step forward. But at this point > in > time, without superset mapping, you cannot model anything more than > trivial relationships. This makes it rather unhelpful, which is a shame > because it's actually quite easy to use. You have to understand, it's easy to use because the mapping is simple and clear. I am trying to avoid frameworkification in SQLObject, which is a difficult task. To me, exposed object hierarchies are one of the creepers which can overwhelm a project if left unchecked. Now, I'm not sure if that's the case with this example, since the object hierarchies we're talking about are in user code, not the library code. Still, I'm wary of all things inheritance-related. Call it the Zope syndrome. My intention with SQLObject is not that it be all things to all people, but rather that you can build all things on it. The more complex SQLObject is, the more disconnect there will be when the complexity of your problem doesn't match the complexity of SQLObject. As it is SQLObject is clearly an easier foundation for building superset objects than the DBAPI. To do so it may be a little ad hoc right now, but you have to build ad hoc designs before generalizing anyway, and a little ad hoc design never killed anyone. Maybe having done that you'll desperately want to generalize this particular recipe. I can only say that I would be much happier seeing it phrased in an explicit manner using composition of objects, rather than inheritance, perhaps because I don't treasure inheritance the way a "real OO programmer" might (which is true), or perhaps because I dislike false cognates and subtle disconnects. > To the developer, how the data is stored is totally irrelevant. But > when > your developer can't actually model relationships because the system of > persistence is restrictive, then we have a problem. I've already > provided > two or three examples that clearly demonstrates that SQLObject can't do > what I want it to do, and I'm hardly trying :-) FWIW, you don't have to code those examples as inheritance, and I naturally wouldn't do so. Composition is quite powerful, even if mundane, and is pleasantly explicit. > And as we all, as good OO developers know, if you build on poor > foundations, you regret it later in life. As all good agile developers know, you make it up as you go along ;) -- Ian Bicking | ia...@co... | http://blog.ianbicking.org |