Re: [SQLObject] Overriding new()..._SO_new()?

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

On Friday, October 10, 2003, at 05:08 PM, Ian Bicking wrote:

> On Friday, October 10, 2003, at 03:18 PM, Brad Bollenbach wrote:
>> On Friday, October 10, 2003, at 11:23 AM, Ian Bicking wrote:
>>>> Am I missing a way in which this can be done, or should SQLObject 
>>>> have an _SO_new?
>>>
>>> You can override new() just like it is.  (Though number 1 can 
>>> probably be handled with a column default)
>>
>> Then what method do I call to access the "original" new once I've 
>> done the overriding? When overriding columns, I'd just use the 
>> _SO_'s, but when overriding new, it's unclear (to me, at least.)
>
> _SO_get_colName is an exception, because the SQLObject class doesn't 
> implement methods for your columns.  But SQLObject implements new(), 
> so you can call SQLObject.new(cls, **kw) (or use super()).

I've hacked this in, but I still don't quite agree with this 
implementation-detail-reasoning, for a few reasons:

1. I'm calling SQLObject.new, instead of TableName.new. The "one class 
for one table" metaphor starts losing its balance -- I'm used to being 
able to look at the class on which new was called to see the name of 
the table in which the new() row will be created. That's no longer 
applicable here.

2. I have to pass the class instance to the SQLObject.new call, which 
is not the way I'm used to being able to call new.

3. Conceptually, I expect to think of new() as a "method created at 
runtime" too -- and therefore, provided with an _SO_ method like each 
column's property methods -- because (conceptually) it wouldn't know 
how to go about creating my columns until it knows what columns I've 
defined. The implementation detail, however, breaks the metaphor, IMHO.

I'm either being reasonable, picky, stubborn, or all of the above, but 
in the discussion we had on IRC, Sidnei seemed to think _SO_new would 
be useful too.

Thoughts?

--
Brad Bollenbach
BBnet.ca