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

[Ian B. <ia...@co...>]

On Tuesday, October 14, 2003, at 12:49 PM, Brad Bollenbach wrote:
> 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.

Sure you can access the table name and all that stuff.  
SQLObject.new(cls, **kw) calls the SQLObject.new *method*, but the 
*class* (cls) is still your TableName class.

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

That's just the way Python works, this is how you call a superclass.  
Or use super(cls).new(**kw), which should work fine too (except maybe 
in some early versions of 2.2 that are buggy).  The two are equivalent.

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

The only methods created at runtime are the column and join methods, 
because (from the SQLObject class's perspective) there are an unknown 
number of these methods, with unknown names.  These created methods are 
all very small, and point to methods defined in the SQLObject class.

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

Yep, picky and stubborn  ;)

You could argue that SQLObject shouldn't use inheritance, and that the 
mechanics of persistence should be put in a separate object.  This 
isn't unreasonable, and maybe it could happen at some time -- maybe Col 
and its subclasses would turn into descriptors (akin to property), and 
you'd define the mapping in some prescribed instance variable (and that 
mapping would subclass from some SQLObject class).  But cls._SO_new vs. 
SQLObject.new is only a trivial side effect of subclassing.

--
Ian Bicking | ia...@co... | http://blog.ianbicking.org