On 20 Aug 2012, at 8:22 PM, Massimo Di Pierro <massimo.dipie...@gmail.com> wrote: > How is this different than > > Field(...readable=True) > > You still have to put the readable=True somewhere. Why put it in a callback > (ondefine) instead of where it belongs?
It's not necessary in this example. I use stuff like that where I want to make the requirements conditional on the controller/function that's being called. More generally: why does *anyone* put requirements outside the Field constructors? There are plenty of them in the book. The point of the construct I'm proposing is to permit it, for whatever reason, but lazily. > > On Monday, 20 August 2012 16:36:22 UTC-5, Jonathan Lundell wrote: > On 20 Aug 2012, at 10:32 AM, Massimo Di Pierro <massimo....@gmail.com> wrote: > > can you show a proof of concept? > > Not exactly a proof, but a concept. > > At the very end of lazy_define_table, just before 'return table': > > if args.get('on_define'): > args.get('on_define')(table) > > The caller-defined on_define function can do things like: > > def on_define(table): > table.field.readable = True > > or, more interestingly: > > def on_define(table): > if request.something == whatever: > table.field.readable = True > > ...etc. Assuming that there's dynamic stuff like that going on, it saves > having to figure out whether you're in a request in which the table is going > to be instantiated and then modify the fields. > > One more thought, just an abstract one because I don't have an example to > offer. Since we're storing args at define_table time, to be used later when > the table is referenced, it's important that the caller not include mutable > objects in args and change them (in relevant ways) between the define_table > call and the instantiation. > > > > > > On Monday, 20 August 2012 11:51:27 UTC-5, Jonathan Lundell wrote: > > On 18 Aug 2012, at 1:46 PM, Massimo Di Pierro <massimo....@gmail.com> > > wrote: > >> As Bruno says. Something like this will completely nullify the benefit of > >> lazy tables. > >> > >> Field(..., readable=True) is OK but > >> db.table.field.readable=True is BAD because will force db.table to be > >> instantiated. > >> > > > > Here's a vague idea: suppose define_table had a requirements parameter, > > defaulting to None, that could be set to a function (lambda or otherwise) > > that would be called after the table is instantiated? Then you'd still be > > able to pull your dynamic requirements into one place, but without > > triggering define-time instantiation. For convenience, the function would > > be called for any instantiation, even a non-lazy one, so one could turn > > lazy instantiation on & off for testing without changing it. > > > > > > -- > > > --