Re: [SQLObject] ezSqlObject convenience wrapper

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

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".

We're talking about a bleeding edge source code repository here; 
patches truly are welcome. Your volunteer efforts are warmly received.

>> As well, some of these features don't make sense (e.g. I'm not sure 
>> what len() on a table is supposed to tell me
>
> len(sometable) simply returns the number of rows in the table.

Oh, I wouldn't have expected that, but that's an aside to the main 
issue.

>> [number of columns perhaps?], but len() on a SelectResults is already 
>> done by using the count() method on an instance.)
>
> len(something) is slightly more readable and convenient.

As Ian mentioned, that was specifically removed from SQLObject a little 
while back.

>> Just ask Ian for checkin privileges (if you don't already have), 
>> write unit tests to demonstrate how you want your new features to 
>> work, and add them and the code that passes those tests to SQLObject 
>> directly.
>
> I wouldn't presume to ask for the ability to maul someone else's 
> codebase when I've just drifted in off the net, I'm not known, and 
> there hasn't been time for a trust relationship to develop.

There's no better way to quickly establish a trust relationship than by 
having some unit tests and code that passes them ready to submit. :) At 
the least, you could pass it through one of the committers hands 
(myself included) to get us to merge it for you. If there's any concern 
about merging it with HEAD (or whatever svn calls HEAD), then we could 
just create a branch with those specific changes and wait until they've 
been tried and discussed enough to consider merging them into the HEAD.

Make no mistake, your volunteer time contributed to helping SQLObject 
is well received, I just think that putting your changes into a 
separate module is (for reasons already mentioned) a mistake.

--
Brad Bollenbach