Marius, Back when I wrote the mapper stuff, there were a bunch of limitations of using vals:
- Because of uniform access rules, the difference between val foo = new
Thing ; def bar = foo was not possible to calculate. It looks like the
compiler now stores things in a named field, so looking for method/fields
with the same name that also inherit from Field should allow us to figure
things out.
- In the past if you had extra methods on a val field, they would not be
visible to a caller. This has been relaxed because of structural types.
On the plus side, there's a minor speed advantage to accessing vals, but
objects are created lazily. See the enclosed code.
Personally, I like to "object" stuff because I'm used to it and it also
distinguishes the stuff to be persisted, but I'm not strongly wedded to
keeping things the way they are.
Thanks,
David
On Sun, Nov 30, 2008 at 8:17 AM, Marius Danciu <[EMAIL PROTECTED]>wrote:
> Hi Dave,
>
> Do you think it worth do goon this route?
>
> class Person extends Record[Person] {
>
> def meta = PersonMeta
>
> val firstName = new StringField(this, "Marius")
>
> val lastName = new StringField(this, "Danciu")
> }
>
>
> like using val-sfor fields, instead of object? ... Allowing this style,
> required only some minor updated in MetaRecord ro make it work. What do you
> think would be the downsides?
>
> Br's,
> Marius
>
--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
ValObj.scala
Description: Binary data
