I agree. Fields should be perfectly functional by just overriding members.
But it should be mentioned in docs, etc as Lift "best practices" to not add
methods or fields inside of Fields.
--j
On Tue, Dec 2, 2008 at 1:01 PM, Marius <[EMAIL PROTECTED]> wrote:
>
> Quite right ... still I don't quite see why someone would use a Field
> as structural type (.. or as anonymous instance) and define new -
> overridden functions and invoke them later. Field should only override
> functions to adapt the behavior for the needed situation.
>
> Nevertheless it is a very good observation !
>
> Br's,
> Marius
>
> On Dec 2, 8:51 pm, "Jorge Ortiz" <[EMAIL PROTECTED]> wrote:
> > class Foo
> >
> > // type is singleton type Bar.type
> > object Bar extends Foo {
> > def exc = (new Exception).printStackTrace
> > }
> >
> > // type is structural type Foo{def exc: Unit}
> > val Baz = new Foo {
> > def exc = (new Exception).printStackTrace
> > }
> >
> > // compare:
> > Bar.exc
> > Baz.exc
> >
> > Singleton types get their own .class file. Structural types use
> reflection.
> >
> > --j
> >
> > On Tue, Dec 2, 2008 at 12:33 PM, Alex Boisvert <[EMAIL PROTECTED]>
> wrote:
> > > On Tue, Dec 2, 2008 at 10:24 AM, Jorge Ortiz <[EMAIL PROTECTED]
> >wrote:
> >
> > >> If you add (non-overriden) fields to a val, they'll always be invoked
> via
> > >> reflection, which takes a performance hit. Objects, on the other hand,
> > >> define their own class so reflection isn't necessary.
> >
> > > Can you give an example? I can't picture this from your description.
> >
> > > alex
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
