Re: [SQLObject] ezSqlObject convenience wrapper

[Brad B. <br...@bb...>]

On Monday, March 8, 2004, at 04:31  PM, Ian Bicking wrote:

> Brad Bollenbach wrote:
>> I cannot speak for Ian obviously, though I have a pretty good hunch 
>> that if somebody sent him a big patch for SQLObject that looked 
>> anywhere near mildly sane, he'd either a.) merge it himself, or b.) 
>> offer checkin access, with the specification that it be checked in on 
>> a branch (which, for anyone who floats around the CVS repositories of 
>> Open Source projects knows that using branches for this kind of thing 
>> is standard procedure. Yes, I know, SQLObject is using svn now, but 
>> same idea.)
>
> I can't say that's entirely true.  Well, it sure better be more than 
> just "mildly sane" for one thing ;)
>
> SQLObject is starting to get a point of maturity where changes have to 
> be well thought out, because they effect backward compatibility, and 
> documented interfaces are something that should be retained for future 
> compatibility.  So I don't want bad or inferior interfaces to get into 
> SQLObject.  "Bad" or "inferior" is obviously a subjective 
> consideration, and has a lot to do with SQLObject's current and future 
> scope.  A good interface solves several of the open problems with 
> SQLObject, though any one person may only need one problem solved and 
> a different or simpler API might seem clear to that person.
>
> I do feel a certain ownership of SQLObject and its direction, so I 
> want to be involved in the design of its API, certainly in a more 
> direct way than "here's a patch to apply."  That shouldn't keep people 
> from going off and experimenting on their own, though, it just means 
> that their results would probably have to be revisited and refactored 
> when it comes back to SQLObject.

The desire to avoid bad or inferior interfaces getting into SQLObject 
is obvious, which is why I made repeated reference to doing 
experimental stuff like this, or inheritance, or any creative new idea 
on a branch (and, in so doing, at least be able to keep it all in the 
name namespace/conceptual box.) This is the way most projects handle 
this sort of thing (e.g. Zope 3, Plone, Python core etc.) Again, if 
somebody created a new module everytime they wanted to add a few new 
attributes to some of SQLObject's classes, we'd have five or six of 
these different modules floating around in no time.

Sorry guys, I'm glad we have people contributing their time and code, 
but I officially give up trying to be the voice of reason here. :)

--
Brad Bollenbach