[scala] From JPA question to ScalaQuery to Collection Abstractions
|
View:
New views
1 Messages
—
Rating Filter:
Alert me
|
 |
[scala] From JPA question to ScalaQuery to Collection Abstractions
by Meredith Gregory
::
Rate this Message:
All,
Again -- many thanks to the posters and responders on this thread. i've moved on to attempt to use ScalaQuery as the target for the SQL persistence. Stefan Szeiger describes his work here. It seems to be a week of meeting resistance, however. i've been attempting to build the simplest possible collection to use as a toy to test my compilation strategy. This has turned out to be quite a little brain-teaser. For me simpler means: contains less information. In this sense, a Set is simpler than a List. The simplest possible collection i can imagine (that still supports associativity -- and i don't know if i can call something that doesn't support associativity a collection) is a monad. A monad doesn't commit to what the collection contains; only parametrically commits to how to put things into the collection; and only parametrically commits to how to flatten the collection (which is tantamount to supporting associativity). After thinking about it for half a day, and revisiting the Moors-Piessens-Odersky (MPO) paper on higher-kinded types, i realized that the MPO construction doesn't actually apply to Scala in practice (someone please tell me if i'm wrong) because they fundamentally rely on constructions using type members and not type parameters. Unfortunately, most of the collections libraries are written using type parameters. So, i decided to roll my own and see what i got. Here's what i came up with last night. // smallest expression of monad i can find trait MBrace[C[_] <: MBrace[C,A],A] { def nest( a : A ) : C[A] def flatten[T <: C[C[A]]]( bsq : T ) : C[A] } // one of the simplest witnesses of monad i can find class MBraceSeq[A]( a_ : A* ) extends Seq[A] with MBrace[MBraceSeq,A] { override def nest( a : A ) = new MBraceSeq[A]( a ) override def flatten[T <: MBraceSeq[MBraceSeq[A]]]( bsq : T ) : MBraceSeq[A] = { (new MBraceSeq[A]( ) /: bsq)( { ( acc : MBraceSeq[A], e : MBraceSeq[A] ) => ( acc ++ e ).asInstanceOf[MBraceSeq[A]] } ) } override def length = a_.length override def elements = a_.elements override def apply( n : Int ) = a_.apply( n ) } i was mostly ok with this -- apart from some desiderata/concerns regarding the Seq methods being visible at this level. i woke up this am and realized that this is not even wrong. It requires an instance of MBrace to invoke the nest or flatten methods. Geez, i feel like a first year undergrad. All i want to do is write the simplest possible collection on which i can then test a persistence strategry and i run into roadblocks everywhere. ;-) Best wishes, --greg On Wed, Jun 24, 2009 at 8:00 AM, Derek Chen-Becker <dchenbecker@...> wrote: Well, in my real-world experience I've never had very complex models and I've never used TABLE-PER-CLASS either, so I don't really have a feel for what's not possible. Generally I think that JPA (which is a subset of Hibernate) covers a good portion of people's needs for ORM, but it definitely has some big missing functionality (e.g. no ordered collections until JPA 2). I think that in this case Greg is pushing the limits on a relatively unused corner of JPA (I've never seen someone use TABLE-PER-CLASS before) and he's hitting some bugs. I want to make clear that I think that what Greg is attempting is entirely possible. My earlier comment about rolling your own ORM was because I misunderstood what he was doing with abstract classes. In my mind, there would be a couple of places where you might want to roll your own stuff: -- L.G. Meredith Managing Partner Biosimilarity LLC 1219 NW 83rd St Seattle, WA 98117 +1 206.650.3740 http://biosimilarity.blogspot.com |
| Free embeddable forum powered by Nabble | Forum Help |
