OK. When you said the old "normal" virtual fields were now "discouraged", I
thought you were implying all virtual fields should be lazy, but sounds like
we still want the lazy/non-lazy distinction, just with a new way of doing
both (both internally and API).
Thanks for clarifying.
Anthony
On Saturday, August 20, 2011 12:26:15 PM UTC-4, Massimo Di Pierro wrote:
> I think we could deprecate the old virtual fields. Yet the new syntax
> (for now experimental) has two APIs:
>
> db.x.f = Field.Virtual(a.f)
> db.x.g = Field.Lazy(a.g)
>
>
> because one maps into row.x.f (an attribute, compute at the time of
> select) and one into row.x.g() (a method to be called later). I think
> we need to keep the distinction. The problem with the old syntax was
> the syntax was the verbosity but also the lack of distinction. It
> lacked a way to do the equivalent of Field.Lazy.
>
> In trunk there is also an extension of the old syntax and a
> "@lazy_virtual". Perhaps this is no longer necessary. Yet it is
> constitues no overhead.
>
> On Aug 20, 10:24 am, Anthony <abas...@gmail.com> wrote:
> > Is the plan to deprecate old style (non-lazy) virtual fields? If so, then
>
> > maybe the new lazy virtual fields shouldn't be modified with "lazy"
> > everywhere -- they should just be referred to as "virtual". So, the
> > decorator could just be "@virtualfield", and Field.Virtual() could refer
> to
> > the new lazy virtual field (if we're deprecating old virtual fields, we
> > might not need to bother with the new Field.Virtual() syntax for them, or
>
> > maybe use something like Field.OldVirtual).
> >
> > Anthony
> >
> >
> >
> >
> >
> >
> >
> > On Saturday, August 20, 2011 8:56:09 AM UTC-4, Massimo Di Pierro wrote:
> > > How about we just do this:
> >
> > > db.define_table('x',Field('number','integer'))
> > > if db(db.x).isempty(): [db.x.insert(number=i) for i in range(10)]
> >
> > > db.x.normal_shift = Field.Virtual(lambda row: row.x.number+1)
> > > db.x.lazy_shift = Field.Lazy(lambda row, delta=3: row.x.number+delta)
> >
> > > for row in db(db.x).select():
> > > print row.number, row.normal_shift, row.lazy_shift(8)
> >
> > > It is in trunk already, not as a replacement but as an alternative.
> > > Pros:
> > > - simpler syntax
> > > Cons:
> > > - we can only attach virtual fields to a table not to a join (even if
> > > each table in the joins will have virtual fields)
> > > - they will not appear in crud.read and table forms unless passed
> > > explicitly. (*)
> >
> > > (*) In principle this can be changed as one can envision adding
> > > Field.Virtual in the model and giving them attributes like a label,
> > > comment, etc. But that would require major refactoring.
> >
> > > On Aug 20, 7:04 am, Massimo Di Pierro <massi...@gmail.com>
> > > wrote:
> > > > OK try:
> >
> > > > db=DAL()
> > > > db.define_table('x',Field('number','integer'))
> > > > if db(db.x).isempty(): [db.x.insert(number=i) for i in range(10)]
> >
> > > > from gluon.dal import lazy_virtualfield
> >
> > > > class MyVirtualFields(object):
> > > > # normal virtual
> > > > field
> > > > def normal_shift(self): return self.x.number+1
> > > > # lazy virtual field (because of
> > > > @staticmethod)
> > > > @lazy_virtualfield
> > > > def lazy_shift(self,row,delta=4): return row.x.number+delta
> >
> > > > db.x.virtualfields.append(MyVirtualFields())
> >
> > > > for row in db(db.x).select():
> > > > print row.number, row.normal_shift, row.lazy_shift(8)
> >
> > > > It is better? We have one new API and one import. I do not like so
> > > > much the try of adding a __lazy__ attribute to the function because,
> > > > in the future the function may be a class with a __call__ method and
> > > > te decorator would mess up class attributes.... perhaps we should
> > > > this dicusssion and tests on web2py-delevelopers
> >
> > > > Massimo
> >
> > > > On Aug 20, 6:46 am, Massimo Di Pierro <massi...@gmail.com>
> > > > wrote:
> >
> > > > > Yes but if we use lazy we have to define and import it from
> somewhere.
> > > > > There is another reason. Using staticmethod we can also do
> >
> > > > > class A(): pass
> > > > > a=A()
> >
> > > > > a.f=lambda(instance,row,*a,**b): return 'lazy value'
> > > > > a.g=lambda(instance,row,*a,**b): return 'lazy value'
> > > > > a.h=lambda(instance,row,*a,**b): return 'lazy value'
> >
> > > > > db.table.virtualfields.append(a)
> >
> > > > > Lat me give it a try anyway...
> >
> > > > > On Aug 20, 5:51 am, Bruno Rocha <roch...@gmail.com> wrote:
> >
> > > > > > why static_method is used to define this? not better to have
> some
> > > @lazy
> > > > > > decorator?
