From: Ian B. <ia...@co...> - 2005-01-31 18:26:57
|
OK, I'm going to figure the inheritance discussion is sleeping for now. So, some things I'd like to change (and maybe with these changes in place, the inheritance discussion can be restarted in a new light). These are in order, in that I think the earlier things will make the later things easier to implement. * Move to py.test for the unit tests: http://codespeak.net/py/current/doc/test.html -- also refactor the tests into smaller modules. I've experimented with this a bit with the SQLObject tests, and I'm pretty happy with the results. If the tests are simple enough, I'm hoping people will be able to report bugs with a failing test case. * Simplify the metaclass, using some of the techniques I talked about in some recent emails -- basically generalizing the way the metaclass looks for magic attributes. I'm going to ask around for ideas about naming and standards, since I feel like there should be some standard even if there isn't. * Simplify Col objects; the signature for SOCol is kind of crazy ;) I think the declarative module might make this more accessible. * Add a sqlmeta class/object to hold the SQLObject API. This way your base instances will have all the methods you specifically indicated (e.g., methods for each attribute), and some basic methods (like .destroySelf, select), but all the reflection methods will go here. Hrm... I'm not 100% set on this, OTOH I dislike all the _SO_something attributes that we have right now hanging off the main instance, and I'm not psyched about adding lots of reflection methods to the main class/instances. Opinions? * Turn Col objects into descriptors. * Simplify Join objects. I want it to be clear how to create your own custom joins. * Get rid of .q -- instead of Person.q.firstName, you can use Person.firstName. I'll leave .q in for backward compatibility, but it's change so Person.q is Person. These are all basically internal refactorings, which shouldn't effect the user API much. I don't envision any backward compatibility issues, unless you are using undocumented/unstable APIs; the advantage, some of those undocumented APIs will become documented and stable when they are changed. I think once things are cleaned up it'll feel easier to add more features. Well, there's also some DBConnection refactoring that could take place, but I don't want to get ahead of myself. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Carlos R. <car...@gm...> - 2005-01-31 19:09:54
|
On Mon, 31 Jan 2005 12:25:41 -0600, Ian Bicking <ia...@co...> wrote: > * Simplify the metaclass, using some of the techniques I talked about in > some recent emails -- basically generalizing the way the metaclass looks > for magic attributes. I'm going to ask around for ideas about naming > and standards, since I feel like there should be some standard even if > there isn't. While you're at it, please consider making declarative a stand-alone module. It will make reuse simpler. It will also make easier to exchange ideas, techniques and even code with other similar projects (such as my own, MetaTemplate) without introducing too much coupling with SQLObject and other projects of yours, such as FormEncode, etc. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: car...@gm... mail: car...@ya... |
From: Ian B. <ia...@co...> - 2005-01-31 19:17:49
|
Carlos Ribeiro wrote: > On Mon, 31 Jan 2005 12:25:41 -0600, Ian Bicking <ia...@co...> wrote: > >>* Simplify the metaclass, using some of the techniques I talked about in >>some recent emails -- basically generalizing the way the metaclass looks >>for magic attributes. I'm going to ask around for ideas about naming >>and standards, since I feel like there should be some standard even if >>there isn't. > > > While you're at it, please consider making declarative a stand-alone > module. It will make reuse simpler. It will also make easier to > exchange ideas, techniques and even code with other similar projects > (such as my own, MetaTemplate) without introducing too much coupling > with SQLObject and other projects of yours, such as FormEncode, etc. I wouldn't add FormEncode as a prerequesite. But then I don't really want to add any prerequesite, which probably means I'd just copy over the module. It's too small as it is to become a stand-alone module, and if this is fully developed it turns into another PEAK-like framework, which is strategically questionable. So we're left with copy and paste :-/ -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Carlos R. <car...@gm...> - 2005-01-31 19:58:38
|
On Mon, 31 Jan 2005 13:16:36 -0600, Ian Bicking <ia...@co...> wrote: > Carlos Ribeiro wrote: > > On Mon, 31 Jan 2005 12:25:41 -0600, Ian Bicking <ia...@co...> wrote: > > > >>* Simplify the metaclass, using some of the techniques I talked about in > >>some recent emails -- basically generalizing the way the metaclass looks > >>for magic attributes. I'm going to ask around for ideas about naming > >>and standards, since I feel like there should be some standard even if > >>there isn't. > > > > > > While you're at it, please consider making declarative a stand-alone > > module. It will make reuse simpler. It will also make easier to > > exchange ideas, techniques and even code with other similar projects > > (such as my own, MetaTemplate) without introducing too much coupling > > with SQLObject and other projects of yours, such as FormEncode, etc. > > I wouldn't add FormEncode as a prerequesite. But then I don't really > want to add any prerequesite, which probably means I'd just copy over > the module. It's too small as it is to become a stand-alone module, and > if this is fully developed it turns into another PEAK-like framework, > which is strategically questionable. So we're left with copy and paste :-/ Sorry, I must have expressed myself badly (it wouldn't be the first time!). What I meant is that declarative is small, self contained, and that it could be factored out from SQLObject & FormEncode; as far as I know, both projects use similar but slightly different code, but this could be factored out. It does not need to become another PEAK-like framework. A separate module makes easier to reuse the code and make experiments, share code, etc. That's the idea: keep it simple, but modular, and easy to reuse. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: car...@gm... mail: car...@ya... |
From: Dave W. <da...@su...> - 2005-01-31 19:28:38
|
Ian, > OK, I'm going to figure the inheritance discussion is sleeping for now. > So, some things I'd like to change (and maybe with these changes in > place, the inheritance discussion can be restarted in a new light). > These are in order, in that I think the earlier things will make the > later things easier to implement. All these sound good to me. One other thing that has been mentioned a fair bit is using parameters rather than complete sql. Do you see that being related to these updates? Dave -- Dave Warnock: http://42.blogs.warnock.me.uk |
From: Ian B. <ia...@co...> - 2005-01-31 19:38:39
|
Dave Warnock wrote: > One other thing that has been mentioned a fair bit is using parameters > rather than complete sql. Do you see that being related to these updates? I'm not sure what you're referring to. You mean things like CompositeKey? Or something else? -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |