[Lift] Re: Why fields are declared as 'object' with Mapper/Record?
to Naftoli: i added implicits as you said and removed all 'onRegister' stuff, i think its useless.. Here's the result: http://github.com/ojow/Random-code/blob/master/RecordRelatedStuff.scala --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Why fields are declared as 'object' with Mapper/Record?
edit: not all 'onRegister' stuff but most of it, only left two points of extension for intercepting the prototype creation. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Why fields are declared as 'object' with Mapper/Record?
On 13 окт, 10:40, David Pollak feeder.of.the.be...@gmail.com wrote: I've got a change on review board that will pick up vals and lazy vals that are MappedFields. Seehttp://reviewboard.liftweb.net/r/40/ However, until certain defects in the Scala compiler (https://lampsvn.epfl.ch/trac/scala/ticket/2463andhttps://lampsvn.epfl.ch/trac/scala/ticket/1006) are fixed, these features are dangerous and should not be used. That's cool! Thanks. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Why fields are declared as 'object' with Mapper/Record?
On Mon, Oct 12, 2009 at 10:15 PM, Oleg G. ojo...@gmail.com wrote: After reading Naftoli's post i checked the way inner object laziness is implemented. And it appears to be not thread safe. It is not threadsafe. This is a known defect and is supposed to be addressed in 2.8. But, the cost of a failure is dual initialization of the field. Following code: class A { val a = 1 } class B { object b extends A } Generates getter for b as follows: public final B$b$ b(); Code: 0: aload_0 1: getfield#18; //Field b$module:LB$b$; 4: ifnonnull 19 7: aload_0 8: new #20; //class B$b$ 11: dup 12: aload_0 13: invokespecial #23; //Method B$b$.init:(LB;)V 16: putfield#18; //Field b$module:LB$b$; 19: aload_0 20: getfield#18; //Field b$module:LB$b$; 23: areturn Looks like its not synchronized? I also looked at lazy vals generated code (when i was thinking on val based Records) and dropped the idea because of synchronization for every single access to a field. That's not the case. There's only a synchronization if the initial non-synchronized test fails. -- 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 -~--~~~~--~~--~--~---
[Lift] Re: Why fields are declared as 'object' with Mapper/Record?
I've spent some time and came up with this code: http://github.com/ojow/Random-code/blob/master/Test.scala I think it should allow all the needed stuff, it keeps meaning with the bytes and also: * its reusable/extensible in many directions, no static stuff * i checked generated .class files and looks like no extra hidden fields or heave methods are generated, so its technically light-weight * it doesn't use/need reflection (not sure if its good or bad) Would be nice to hear some feedback on that. P.S. I'm still a newbie in Scala so excuse me if this code is worthless and if i'm just stealing your time. On Oct 7, 3:54 am, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Oct 6, 2009 at 10:16 AM, Oleg G. ojo...@gmail.com wrote: As i said before i'm not sure that i'm getting the whole picture and maybe my initial question is incorrect in its root. Still: Suppose i have a Person class declared with Mapper/Record and i want to reuse the class and all the code associated with it in another module/project. My first thought was to extend the Person class and override some of its fields by mixing in some additional traits (see my simplified example code in the initial message). But i noticed that inner objects cannot be overriden (its not obvious for me but i can get it if i dig it). You can't do this. There was a Scala language feature that would have allowed this (overriding an object) but it hasn't made the cut for 2.7 or 2.8. So how do i reuse Mapper/Record based code if i need to extend/ customize the data structures? Unfortunately, you can't. Once you've got a field defined, there's nothing you can do to change it in a subclass. On Oct 6, 11:59 pm, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Oct 6, 2009 at 9:50 AM, Oleg G. ojo...@gmail.com wrote: Thanks for all the answers and especially for David's clarification. It would be really cool to upgrade the 'keeping the meaning with the bytes' thing (http://blog.lostlake.org/index.php?/archives/19-Keeping- the-meaning-with-the-bytes.html) to allow extension/customization. What kind of extensions/customizations? MappedXXX can all be subclassed, extended and customized. -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://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 -~--~~~~--~~--~--~---
[Lift] Re: Why fields are declared as 'object' with Mapper/Record?
Well i don't think its a lot of complexity. Yes its 4 declarations instead of 1 for each field. But 3 of those are generatable by IDE same way as any Java IDE generates setters and getters. All the rest is spring-style instantiations/injections. And usage is even simplier and readable (i mean syntax record.field=value). The field list method can be implemented via reflection to reduce amount of code required from users. Anyway thanks for your feedback, David, i really appreciate it. I'll try to see if i can integrate my model with Lift and implement it for Google Datastore. Then i'll report back. I understand that i still need to do more work before any serious conclusions can be made. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Why fields are declared as 'object' with Mapper/Record?
On 13 окт, 00:08, naf g naftoli...@gmail.com wrote: Why do you have two classes, Model and Record? What are they and why are they interdependent? I thought about Model being a place for metainformation (like database structure, options/properties etc), or maybe it can be described as global context for Record-related activity. They are dependant to allow Field operations to reach the context. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Why fields are declared as 'object' with Mapper/Record?
So Model represents the database connection? 2009/10/12 Oleg G. ojo...@gmail.com On 13 окт, 00:08, naf g naftoli...@gmail.com wrote: Why do you have two classes, Model and Record? What are they and why are they interdependent? I thought about Model being a place for metainformation (like database structure, options/properties etc), or maybe it can be described as global context for Record-related activity. They are dependant to allow Field operations to reach the context. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Why fields are declared as 'object' with Mapper/Record?
On Mon, Oct 12, 2009 at 10:38 AM, Oleg G. ojo...@gmail.com wrote: Well i don't think its a lot of complexity. You asked for feedback, I gave you my opinion. Yes its 4 declarations instead of 1 for each field. But 3 of those are generatable by IDE same way as any Java IDE generates setters and getters. And this is a failure on its face. Anything that requires an IDE to generate code represents a failure. It represents failure because the code is (1) much less maintainable, (2) depends on IDE vendors to support it, and (3) is harder for non-IDE users (me included... emacs is my tool for a lot of my Lift-based development). All the rest is spring-style instantiations/injections. And usage is even simplier and readable (i mean syntax record.field=value). The field list method can be implemented via reflection to reduce amount of code required from users. Calculating what fields are to be included in the List is what originally led to using object. Anyway thanks for your feedback, David, i really appreciate it. I'll try to see if i can integrate my model with Lift and implement it for Google Datastore. Then i'll report back. I understand that i still need to do more work before any serious conclusions can be made. While I appreciate your effort, it is is not in line with the goals of Lift. The default is not to keep the meaning with the bytes (having _name implies to me don't use this, use name instead). The complexity is significant... so significant that it requires IDE support to use effectively. The problem that it addresses is the overriding definitions of fields in subclasses issue which is important, but in this case the cure is much, much worse than disease. Thanks, David -- 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 -~--~~~~--~~--~--~---
[Lift] Re: Why fields are declared as 'object' with Mapper/Record?
Thanks again for your answers, David. I've got your point and it all looks much more clear to me now. On 13 окт, 01:19, David Pollak feeder.of.the.be...@gmail.com wrote: On Mon, Oct 12, 2009 at 10:38 AM, Oleg G. ojo...@gmail.com wrote: Well i don't think its a lot of complexity. You asked for feedback, I gave you my opinion. Yes its 4 declarations instead of 1 for each field. But 3 of those are generatable by IDE same way as any Java IDE generates setters and getters. And this is a failure on its face. Anything that requires an IDE to generate code represents a failure. It represents failure because the code is (1) much less maintainable, (2) depends on IDE vendors to support it, and (3) is harder for non-IDE users (me included... emacs is my tool for a lot of my Lift-based development). All the rest is spring-style instantiations/injections. And usage is even simplier and readable (i mean syntax record.field=value). The field list method can be implemented via reflection to reduce amount of code required from users. Calculating what fields are to be included in the List is what originally led to using object. Anyway thanks for your feedback, David, i really appreciate it. I'll try to see if i can integrate my model with Lift and implement it for Google Datastore. Then i'll report back. I understand that i still need to do more work before any serious conclusions can be made. While I appreciate your effort, it is is not in line with the goals of Lift. The default is not to keep the meaning with the bytes (having _name implies to me don't use this, use name instead). The complexity is significant... so significant that it requires IDE support to use effectively. The problem that it addresses is the overriding definitions of fields in subclasses issue which is important, but in this case the cure is much, much worse than disease. Thanks, David -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://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 -~--~~~~--~~--~--~---
[Lift] Re: Why fields are declared as 'object' with Mapper/Record?
I've got a change on review board that will pick up vals and lazy vals that are MappedFields. See http://reviewboard.liftweb.net/r/40/ However, until certain defects in the Scala compiler ( https://lampsvn.epfl.ch/trac/scala/ticket/2463 and https://lampsvn.epfl.ch/trac/scala/ticket/1006) are fixed, these features are dangerous and should not be used. 2009/10/12 Oleg G. ojo...@gmail.com Very interesting reading, Naftoli! Thanks alot for such extensive explainations. I'm going to read your message again and again until i understand it all :) On 13 окт, 02:09, Naftoli Gugenheim naftoli...@gmail.com wrote: 1. Personally I would not take the approach of creating a totally new ORM with a completely new paradigm just to eliminate the object syntax. The first step, as with anything in life, is to define our goals. What exactly is it about the object syntax that's problematic? Is overridability a problem? Is reflection evil? Let's make a list of our objectives over here. In any case, I would take the following approach. Currently, the way Mapper works is as follows. Every Mapper instance delegates database actions to its MetaMapper instance, which, upon initialization, builds the information about its fields using reflection, including the list of fields and their names. Three reasons for the object approach were mentioned in this thread. 1. To allow access to members. It was mentioned that this is now possible with anonymous classes (val x = new Y { ... } ). What was not mentioned but I read elsewhere IIRC is that the latter is implemented by scalac via reflection. Not that that's the end of the world, especially as we're relying on reflection as it is. Also, at least the argument remains--allow one to choose whichever syntax one desires. On the other hand, if Mapper would not use reflection, objects, being lazy, would not be known about until initialized, thus requiring the user to manually reference them. 2. To disambiguate members that reference or return other fields. However, this argument assumes that the list of fields is built via reflection; maybe it should not be. 3. To allow the field names to become available via reflection. I don't there's any way around this other than a compiler plugin (or maybe scala.reflect.Code?) So my suggestion would require passing the field name to a constructor. On the other hand, as I mentioned in a previous post and will explain better below, passing this to the constructor can be eliminated. So the first reason basically says, since people may need to use 'object,' and objects are lazy and we won't necessarily know about them, we had better use reflection. On the other hand, if we use vals most of the time, the constructor itself can inform the MetaMapper of its existence, and if someone wants to use 'object' or 'lazy val' then they will be required to initialize it before using it with Mapper. The second reason is eliminated if we don't use reflection. The third reason remains valid but the question is how important it is, at the expense of preventing subclasses from overriding fields. If it is acceptable to eliminate the this parameter and instead require a field name parameter, then it would seem possible to use a val based system instead of an object + reflection system. Here is how it would work. class Field(name: String)(implicit meta: MetaModel) { meta.register(this)} class Model { implicit def meta = getSingleton} class MyModel extends Model { val field1 = new Field(firstname) // meta gets passed automatically val fieldRef = field1 // doesn't cause duplication because fields are registered on instantiation} val fieldX = new Field(lastname) // compiler error because no implicit MetaModel in scope val fieldY = new Field(xxx)(MyModelMeta) // works, but obviously a bad idea Two points. 1. The concept of the meta being passed implicitly could probably be implemented into the current system. The only thing it has to do with this discussion is that if you would have to pass 'this' and the field name it would be really verbose, so I'm just pointing out that we could have a non-reflection-based system with about the same verbosity that we use now, although we could make the current system less verbose too. 2. On the surface it would seem impossible to implement this in Mapper, because by not using reflection there's no way to get all the object members since objects are lazy. However since the reflection system only picks up objects and not vals, one could solve this as follows. As long as the same field cannot be registered twice, i.e., registration of a field skips it if it's already registered, there's no problem with allowing both methods to exist side by side. Let
[Lift] Re: Why fields are declared as 'object' with Mapper/Record?
After reading Naftoli's post i checked the way inner object laziness is implemented. And it appears to be not thread safe. Following code: class A { val a = 1 } class B { object b extends A } Generates getter for b as follows: public final B$b$ b(); Code: 0: aload_0 1: getfield#18; //Field b$module:LB$b$; 4: ifnonnull 19 7: aload_0 8: new #20; //class B$b$ 11: dup 12: aload_0 13: invokespecial #23; //Method B$b$.init:(LB;)V 16: putfield#18; //Field b$module:LB$b$; 19: aload_0 20: getfield#18; //Field b$module:LB$b$; 23: areturn Looks like its not synchronized? I also looked at lazy vals generated code (when i was thinking on val based Records) and dropped the idea because of synchronization for every single access to a field. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Why fields are declared as 'object' with Mapper/Record?
Well, I am only a beginner myself but here are my 2 cents: - My guess is that they are declared as inner objects to make it possible to reach certain global field properties through the companion MetaMapper object. - As far as I know traits cannot be directly instantiated, only extended or mixed in. Dirk Louwers On Oct 6, 8:38 am, Oleg G. ojo...@gmail.com wrote: Sorry if its a stupid question, but why? I like the idea very much and trying to understand all the aspects. Fields declared as 'objects' can't be overridden. Is it intended? If so why? Consider following oversimplified example: trait Field trait Prop1 trait Prop2 trait Prop3 class Person { val name = new Field with Prop1 with Prop2 } class CustomPerson extends Person { override val name = new Field with Prop1 with Prop2 with Prop3 } Is there something wrong? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Why fields are declared as 'object' with Mapper/Record?
One major reason for the inner object pattern is that when you have a singleton object extending a trait, it is possible for the trait to reflect upon that object's class to obtain information like the name of the field. You'll see this pattern used throughout Lift (AnyVar subclasses RequestVar and SessionVar *must* be instantiated as objects - if you do something like this: class StringRequestVar(x: = String) extends RequestVar[String](x) object MyState { val v1 = new StringRequestVar(foo) val v2 = new StringRequestVar(bar) } then v2 will actually stomp on v1 at instantiation, and any assignment to v1 will stomp on v2 and vice versa. (I don't really care for this pattern either, but understand the justification for it.) Kris On Tue, Oct 6, 2009 at 12:38 AM, Oleg G. ojo...@gmail.com wrote: Sorry if its a stupid question, but why? I like the idea very much and trying to understand all the aspects. Fields declared as 'objects' can't be overridden. Is it intended? If so why? Consider following oversimplified example: trait Field trait Prop1 trait Prop2 trait Prop3 class Person { val name = new Field with Prop1 with Prop2 } class CustomPerson extends Person { override val name = new Field with Prop1 with Prop2 with Prop3 } Is there something wrong? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Why fields are declared as 'object' with Mapper/Record?
On Tue, Oct 6, 2009 at 7:52 AM, Kris Nuttycombe kris.nuttyco...@gmail.comwrote: One major reason for the inner object pattern is that when you have a singleton object extending a trait, it is possible for the trait to reflect upon that object's class to obtain information like the name of the field. You'll see this pattern used throughout Lift (AnyVar subclasses RequestVar and SessionVar *must* be instantiated as objects - if you do something like this: class StringRequestVar(x: = String) extends RequestVar[String](x) object MyState { val v1 = new StringRequestVar(foo) val v2 = new StringRequestVar(bar) } then v2 will actually stomp on v1 at instantiation, and any assignment to v1 will stomp on v2 and vice versa. (I don't really care for this pattern either, but understand the justification for it.) 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. In terms of the RequestVar stuff, the RequestVar and SessionVar generates its unique name (so it knows how to put itself in a unique place in backing store) based on its class and each SessionVar and RequestVar have a unique class name based on being a subclass of RequestVar rather than an instance of RequestVar. Hope this help. Thanks, David Kris On Tue, Oct 6, 2009 at 12:38 AM, Oleg G. ojo...@gmail.com wrote: Sorry if its a stupid question, but why? I like the idea very much and trying to understand all the aspects. Fields declared as 'objects' can't be overridden. Is it intended? If so why? Consider following oversimplified example: trait Field trait Prop1 trait Prop2 trait Prop3 class Person { val name = new Field with Prop1 with Prop2 } class CustomPerson extends Person { override val name = new Field with Prop1 with Prop2 with Prop3 } Is there something wrong? -- 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 -~--~~~~--~~--~--~---
[Lift] Re: Why fields are declared as 'object' with Mapper/Record?
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. Is there any reason (other than time constraints) to not update the Record framework to take advantage of the newer language features? Tim --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Why fields are declared as 'object' with Mapper/Record?
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 -~--~~~~--~~--~--~---
[Lift] Re: Why fields are declared as 'object' with Mapper/Record?
Thanks for all the answers and especially for David's clarification. It would be really cool to upgrade the 'keeping the meaning with the bytes' thing (http://blog.lostlake.org/index.php?/archives/19-Keeping- the-meaning-with-the-bytes.html) to allow extension/customization. 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 frameworkhttp://liftweb.net Beginning Scalahttp://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 -~--~~~~--~~--~--~---
[Lift] Re: Why fields are declared as 'object' with Mapper/Record?
On Tue, Oct 6, 2009 at 9:50 AM, Oleg G. ojo...@gmail.com wrote: Thanks for all the answers and especially for David's clarification. It would be really cool to upgrade the 'keeping the meaning with the bytes' thing (http://blog.lostlake.org/index.php?/archives/19-Keeping- the-meaning-with-the-bytes.html) to allow extension/customization. What kind of extensions/customizations? MappedXXX can all be subclassed, extended and customized. 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 frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics -- 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 -~--~~~~--~~--~--~---
[Lift] Re: Why fields are declared as 'object' with Mapper/Record?
As i said before i'm not sure that i'm getting the whole picture and maybe my initial question is incorrect in its root. Still: Suppose i have a Person class declared with Mapper/Record and i want to reuse the class and all the code associated with it in another module/project. My first thought was to extend the Person class and override some of its fields by mixing in some additional traits (see my simplified example code in the initial message). But i noticed that inner objects cannot be overriden (its not obvious for me but i can get it if i dig it). So how do i reuse Mapper/Record based code if i need to extend/ customize the data structures? On Oct 6, 11:59 pm, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Oct 6, 2009 at 9:50 AM, Oleg G. ojo...@gmail.com wrote: Thanks for all the answers and especially for David's clarification. It would be really cool to upgrade the 'keeping the meaning with the bytes' thing (http://blog.lostlake.org/index.php?/archives/19-Keeping- the-meaning-with-the-bytes.html) to allow extension/customization. What kind of extensions/customizations? MappedXXX can all be subclassed, extended and customized. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Why fields are declared as 'object' with Mapper/Record?
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 Pollakfeeder.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 -~--~~~~--~~--~--~---
[Lift] Re: Why fields are declared as 'object' with Mapper/Record?
I hope I don't wander too far off-topic here as I wend my way to the question at the end of this post (would it be useful to look at something like the OWL/SWRL web ontology and rule languages for liftweb?). I tend to generalize/abstract a lot - so if anyone with a theoretical bent is willing to peruse the following, I would appreciate any feedback as to whether it could be applicable to liftweb. Basically I just want to wonder out loud here whether support in liftweb for some of the specific ideas referenced in this thread (particularly the keeping the meaning with the bytes thing) could be helped along by looking at some possibly related theoretical work being done involving contexts and policies for web services, eg here: http://www.csee.umbc.edu/swpw/papers/ PDF! - http://www.csee.umbc.edu/swpw/papers/denker.pdf Some of this admittedly theoretical work from this particular conference is being implemented in machine-executable languages (eg, Maude) which are also fortunately quite close to Scala, thanks to Scala's support for both the functional and the object-oriented programming paradigms. (Maude is similar to Haskell and ML, which are sometimes also compared to Scala.) This means that it might be quite straightforward to map any needed portions of this related theoretical work on policies and contexts for web services from languages such as Maude to liftweb in a fairly straightforward manner. ((Full disclosure: Maude is one of the few languages I know and use, eg for conceptual data modeling of entity-relationship databases: http://www.springerlink.com/content/35gxk6g83vn6q648/ I mention this mainly to show that although I'm still a relative newbie when it comes to web frameworks - particularly regarding security - I do have some background in specification of databases with contraints which I hope could somehow be applicable to database- oriented programming in liftweb.)) I was intrigued by the 2006 post by DP mentioned upthread: http://blog.lostlake.org/index.php?/archives/19-Keeping-the-meaning-with-the-bytes.html where he suggests some excellent web framework design principles: - The semantic meaning of fields on objects should be retained throughout the field's life. - Conversion to a semantic-free format (String, double, etc.) should be done as late in the field's life-cycle (e.g., a String returned from 'render as HTML') as possible. - Every field of every object {should} be semantically meaningful. - - getSSN() returns an object of SSN class that derives from Taxpayer class that derives from SensitiveIndentifyingInformation class. - - the toHtml() method on the SSN class returns '***-**-' unless the context in which the SSN is being accessed has permissions / grants permissions to see more. - All pieces of the object are defined in a central place. It would just seem that the above-postulated central place could be (built using some of the rich facilities provided by) Scala's type system itself - perhaps even neatly packaged into a kind of liftweb MOP (meta object protocol, like CLOS added to Lisp), or presented as a DSL (domain-specific language). The road from design-time to run-time is of course a sequence of stages where abstraction is concretized and type info is erased - as we move from an SSN, to a String, and eventually to a bunch of pixels on the screen. I would think that the line could be drawn so that the web framework always knows that something is an SSN. I don't know enough about JVMs to understand if or when this kind of type info is eventually erased - but I understand that it's important that a level of abstraction should be provided to the end-programmer using a web framework where this type info is always available, enabling centrally specified policies to make the web app just do the right thing depending on the particular context. Coming back to the problem of providing a completely general framework for specifying policies and contexts: Would any of the theoretical papers from, say, this conference: http://www.csee.umbc.edu/swpw/papers/ provide any useful pointers as to how to approach this? I'm not sure if the implementation languages there seem too ivory- tower, or the conceptual languages there sound too designed by committee (eg, OWL/SWRL), in the eyes of liftweb committers and programmers who might be quite understandably up to their necks in hands-on issues like cross-site scripting attacks etc. But formal, theoretical stuff can have its place, since: (a) Scala itself is based on a rigorous theoretical, formal foundation (b) tools supporting checking of programs written in commercial/ industrial languages (eg, Erlang) are now being written in formal/ academic languages (eg, Maude): (WARNING - PS file!) http://www-i2.informatik.rwth-aachen.de/old/Staff/Current/neuhaeusser/publications/wrla06.ps And Scala's fuctional/object-oriented paradigms and very rich type system (making Scala very close to many formal/academic
[Lift] Re: Why fields are declared as 'object' with Mapper/Record?
On Tue, Oct 6, 2009 at 10:16 AM, Oleg G. ojo...@gmail.com wrote: As i said before i'm not sure that i'm getting the whole picture and maybe my initial question is incorrect in its root. Still: Suppose i have a Person class declared with Mapper/Record and i want to reuse the class and all the code associated with it in another module/project. My first thought was to extend the Person class and override some of its fields by mixing in some additional traits (see my simplified example code in the initial message). But i noticed that inner objects cannot be overriden (its not obvious for me but i can get it if i dig it). You can't do this. There was a Scala language feature that would have allowed this (overriding an object) but it hasn't made the cut for 2.7 or 2.8. So how do i reuse Mapper/Record based code if i need to extend/ customize the data structures? Unfortunately, you can't. Once you've got a field defined, there's nothing you can do to change it in a subclass. On Oct 6, 11:59 pm, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Oct 6, 2009 at 9:50 AM, Oleg G. ojo...@gmail.com wrote: Thanks for all the answers and especially for David's clarification. It would be really cool to upgrade the 'keeping the meaning with the bytes' thing (http://blog.lostlake.org/index.php?/archives/19-Keeping- the-meaning-with-the-bytes.html) to allow extension/customization. What kind of extensions/customizations? MappedXXX can all be subclassed, extended and customized. -- 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 -~--~~~~--~~--~--~---
[Lift] Re: Why fields are declared as 'object' with Mapper/Record?
What you can do if I'm not mistaken, although not as good, is define in a base trait, def myField: MappedXXX ... and give different concrete object implementations. This way you have a common type that guarantees the field. On Tue, Oct 6, 2009 at 4:54 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Oct 6, 2009 at 10:16 AM, Oleg G. ojo...@gmail.com wrote: As i said before i'm not sure that i'm getting the whole picture and maybe my initial question is incorrect in its root. Still: Suppose i have a Person class declared with Mapper/Record and i want to reuse the class and all the code associated with it in another module/project. My first thought was to extend the Person class and override some of its fields by mixing in some additional traits (see my simplified example code in the initial message). But i noticed that inner objects cannot be overriden (its not obvious for me but i can get it if i dig it). You can't do this. There was a Scala language feature that would have allowed this (overriding an object) but it hasn't made the cut for 2.7 or 2.8. So how do i reuse Mapper/Record based code if i need to extend/ customize the data structures? Unfortunately, you can't. Once you've got a field defined, there's nothing you can do to change it in a subclass. On Oct 6, 11:59 pm, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Oct 6, 2009 at 9:50 AM, Oleg G. ojo...@gmail.com wrote: Thanks for all the answers and especially for David's clarification. It would be really cool to upgrade the 'keeping the meaning with the bytes' thing (http://blog.lostlake.org/index.php?/archives/19-Keeping- the-meaning-with-the-bytes.html) to allow extension/customization. What kind of extensions/customizations? MappedXXX can all be subclassed, extended and customized. -- 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 -~--~~~~--~~--~--~---