Yes, i rechecked it and found it's a double checked locking. So lazy
vals is best choice, they are also better for overriding than normal
vals, because normal vals call super initialization.
So it looks like initial problem is now solved and the thread reached
its happy end.
And i want to sincere
On Mon, Oct 12, 2009 at 10:15 PM, Oleg G. 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
On 13 окт, 10:40, David Pollak 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://lamp
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 ema
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
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
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
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 wrote:
> 1. Personally I would not take the approach of creating a totally new ORM
> with a compl
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 p
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 wrote:
> On Mon, Oct 12, 2009 at 10:38 AM, Oleg G. wrote:
>
> > Well i don't think its a lot of complexity.
>
> You asked for feedback, I gave you my opinion.
>
>
On 13 окт, 01:00, Naftoli Gugenheim wrote:
> So Model represents the database connection?
I tried to keep my thoughts at quite high abstraction level for the
sake of flexibility. And i don't have rich enough experience in
implementing object-database mapping to give you good full answer -
also th
On Mon, Oct 12, 2009 at 10:38 AM, Oleg G. 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
> get
So Model represents the database connection?
2009/10/12 Oleg G.
>
> On 13 окт, 00:08, naf g 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/pr
On 13 окт, 00:08, naf g 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-re
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 syn
Why do you have two classes, Model and Record? What are they and why are they
interdependent?
-
David Pollak wrote:
On Mon, Oct 12, 2009 at 1:55 AM, Oleg G. wrote:
>
> I spent some time and came up with this code:
> http://github.com/ojow/Random-code/blob/m
On Mon, Oct 12, 2009 at 1:55 AM, Oleg G. wrote:
>
> I 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 and extensible in many directi
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 lo
I 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 and extensible in many directions
* looks like generated .class files don't have any additi
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
wrote:
>
>
> On Tue, Oct
On Tue, Oct 6, 2009 at 10:16 AM, Oleg G. 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 asso
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 t
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
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 w
On Tue, Oct 6, 2009 at 9:50 AM, Oleg G. 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
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
On Tue, Oct 6, 2009 at 8:20 AM, Tim Nelson 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 met
On Tue, Oct 6, 2009 at 10:10 AM, David Pollak 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 exten
On Tue, Oct 6, 2009 at 7:52 AM, Kris Nuttycombe
wrote:
>
> 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
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
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
31 matches
Mail list logo
