I want to raise another related point.
Currently all mapped fields have to be passed "this". Is there a way to not
require it?
Can Mapper or Record use an implicit object etc. to fill in "this"?
Or could there be an inner derived class that knows its parent, like I recently
did for ModelView? In other words, e.g., a MappedString that is a member of
Mapper and derived from the real MappedString. This option is less optimal
because (1) it's possible it will break code, although not necessarily, and (2)
it cannnot be extended to a MappedField defined outside of lift-mapper. A
similar approach that solves #2 is traits that can be mixed into a Mapper
containing these MappedField subclasses, but it has the disadvantage of
requiring more traits to be mixed in.
In any case, although it is now possible to access members of an anonymous
class, doesn't it currently use reflection? So maybe this is dependent on that
being improved.
On the other hand the advantage of vals is that they don't have to be lazy,
thus eliminating all the reflection necessary to get the list of fields.
To go off topic, maybe it would make sense, in order to allow either vals or
objects *or JPA entities*, a base trait that defines the ability to get
information about fields. A JPA subtrait could use JPA APIs, while the main
Lift subtrait could either use reflection to get the objects, or use eager vals
that populate the entities knowledge of them directly.
-------------------------------------
David Pollak<feeder.of.the.be...@gmail.com> wrote:
On Tue, Oct 6, 2009 at 8:20 AM, Tim Nelson <tnell...@gmail.com> wrote:
>
> On Tue, Oct 6, 2009 at 10:10 AM, David Pollak <
> feeder.of.the.be...@gmail.com> wrote:
>
>>
>> I don't care for the pattern, but it comes from Scala history... so....
>>
>> In the days of Scala 2.3, an inner object had different class and method
>> visibility than a val instantiated in the same way. So, if you had:
>>
>> object foo extends Object { def bar = "You can call me"
>> }
>>
>> You could call bar. However:
>>
>> val foo = new Object { def bar = "You can't call me"
>> }
>>
>> foo would be an Object, not visible as a subclass of Object. So, that's
>> the first reason for object vs. val.
>>
>> The second reason is that it's possible to disambiguate:
>>
>> object foo extends MappedString(this, 32)
>>
>> from
>>
>> var foo: MappedString[OtherThing] = _
>>
>> It may be possible to disambiguate these now, but in the 2.3 days, it
>> wasn't.
>>
>
>
> It sounds like both reasons for using objects are legacy related.
>
Generally, yes. I haven't dived into the reflection-based layout or the
Scala-related reflection stuff in 2.8 deeply enough to say that we could do
a val-based Record implementation.
> Is there any reason (other than time constraints) to not update the Record
> framework to take advantage of the newer language features?
>
> Tim
>
> >
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--~--~---------~--~----~------------~-------~--~----~
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
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
