Re: [SQLObject] ezSqlObject convenience wrapper

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

On Monday, March 8, 2004, at 12:53  AM, Ian Bicking wrote:

> On Mar 7, 2004, at 6:45 PM, Brad Bollenbach wrote:
>> On Sunday, March 7, 2004, at 07:23  PM, David McNab wrote:
>>
>>> Brad Bollenbach wrote:
>>>> It doesn't make any sense to create another module for this.
>>>
>>> I can't say I agree here.
>>>
>>> Wrapper modules are a great way to try out ideas.
>>>
>>> If the core package devs happen to like one or more of the ideas, 
>>> they can always merge them in, or give cvs write access to whover 
>>> wrote the wrapper.
>>>
>>> And if the core devs don't like the ideas, the wrapper writer gets 
>>> to use the wrapped interface in his/her code regardless.
>>>
>>> Nobody loses.
>>
>> Except those of us that don't want to needlessly have to track two 
>> codebases for no reason. :) By following your logic here, it wouldn't 
>> take much for us to suddenly have five or six different "wrapper" 
>> packages to "try out ideas".
>
> But it's a *wrapper*, not a fork.  A wrapper isn't a codebase to track 
> really -- except to the degree that it might use some private 
> interfaces or otherwise be sensitive to changes in the wrapped 
> package.  But that just means the wrapper is tied to a version, or the 
> author has to keep track of changes; it's not that big a deal.
>
> The wrapper is Good Enough for David.  If there are features that 
> other people really like in it, then certainly they can be moved to 
> the main SQLObject code (as long as those other people speak up).  
> Really, time will tell.

The only person who's used the term "fork" here is you. :)

It definitely is another codebase to track (install, import, then when 
the changes do finally get merged, uninstall, change the imports to be 
from where they belong, SQLObject, etc.), which assures that our 
projects that are using SQLObject (and have discovered a few important 
bugs along the way), won't be trying out these changes.

This debate is becoming a pointless "yes it is", "no it isn't" sort of 
thing though, and I can see now I won't be able to make headway on my 
point, but my logic still stands. If everybody approached this 
situation in the same way (e.g. Daniel with inheritance, Sidnei with 
CASCADE and such), we'd have five or six "wrapper" packages like this 
is no time.

--
Brad Bollenbach