Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
John Sullivan
@sullivan-
I've got to get back into using ENSIME more. I'm typically lazy and just use Emacs
Mardo Del Cid
@mardo
not sure if everything is possible though
John Sullivan
@sullivan-
yeah, i still intend to migrate a lot of internals to longevity. but it just takes time. at the moment, I'm putting "schema migrations" at top priority.
Okay, I'm going to install IDEA and take a look
Mardo Del Cid
@mardo
cool
the whole project is awesome
John Sullivan
@sullivan-
thanks man!
Mardo Del Cid
@mardo
One question I was curious about, there’s no support for inheritance in the persisted case classes props, like this for instance:
@persistent[DomainModel]
  case class User(
    username: Username,
    email: Email,
    fullName: FullName,
    answers: List[Answer] = Nil
  )

  trait Answer

  @component[DomainModel]
  case class AAnswer(a: String) extends Answer

  @component[DomainModel]
  case class BAnswer(b: Int) extends Answer
Mardo Del Cid
@mardo
:O !
John Sullivan
@sullivan-
when we move to shapeless we'll have to start sealing that trait
Mardo Del Cid
@mardo
I just had a geekgasm
John Sullivan
@sullivan-
:smile:
Mardo Del Cid
@mardo
I think this polymorphic feature was the deal breaker to choose longevity
in a project I am about to start for a customer
John Sullivan
@sullivan-
thats great to hear
John Sullivan
@sullivan-
Looks like this is the thing to use to get IDEA to understand the macros: https://blog.jetbrains.com/scala/2015/10/14/intellij-api-to-build-scala-macros-support/
Mardo Del Cid
@mardo
The links in there are broken, but I’ll see if I can use information to do a workaround
Here's my longevity about IDEA support: longevityframework/longevity#36
issue that is
@mardo I would be thrilled if you wanted to try either of the approaches I mention in the ticket. Of course the IDEA API approach would be best, but it's going to be a good bit of work, and I'm not even sure up front if their API is flexible enough to make it happen
The "workaround" approach I describe in the ticket would be much more straightforward.
It puts a minor ugly into the longevity API (a method in PType that's not very typesafe), but I'm okay with that. We can put a disclaimer in the scaladocs
John Sullivan
@sullivan-
Just taking a look at longevity src and yeah, that second approach would be very straightforward
Mardo Del Cid
@mardo
I think writing as less boilerplate as possible is the best option
It is really a IDE limitation, not really a framework one. However, a lot of people is using IntelliJ, so maybe the IDEA API approach is the best fit here. I’ll have a look when I have a chance
otherwise, as I said earlier, is not huge deal… it is just happening in the companion objects when defining the indexes (primary keys, keys, and so on…)
;)
Mardo Del Cid
@mardo
Ohhh….
then it is a bigger issue than I initially thought
yeah makes sense, when doing queries we need to access the props, and intellij can’t figure out the props
John Sullivan
@sullivan-
Could you let me know what you find out with the IDEA API? If we learn that that approach isn't going to work, then maybe we should move forward with the second approach
Mardo Del Cid
@mardo
Sure, I’ll give it a shot this evening and get back to you
John Sullivan
@sullivan-
Cool thanks!

when I look here, it is injecting into the class that gets annotated:

https://github.com/JetBrains/intellij-scala/blob/idea172.x/src/org/jetbrains/plugins/scala/lang/psi/impl/toplevel/typedef/MonocleInjector.scala

in which case, it produces a string such as "def foo: Foo = new Foo {}"

so i wonder what kind of string you need to produce to add code into the companion object?
John Sullivan
@sullivan-
wow @mardo , looks like that is going to be a lot of work.
Mardo Del Cid
@mardo
oohhh I see… Not sure about the string though
John Sullivan
@sullivan-
adding support for things like User.key and User.queryDsl probably wouldn't be that difficult
But adding User.props might be a bigger deal
Mardo Del Cid
@mardo
hmmm… as a second thought, if scalameta is in the roadmap, maybe we should consider just ignoring this until that migration?
John Sullivan
@sullivan-
that might make more sense
Mardo Del Cid
@mardo
On the other hand, this could very well be a show stopper for IntelliJ users, I mean I love my vim and can easily switch to that, but many people won’t like that
Not sure when scalameta will have all the features that longevity needs
John Sullivan
@sullivan-
Just checking that.. Here's the roadmap of the general feature - typechecking - that I need: scalameta/scalameta#604
So one thing we could do is add the def mprop[A](propName: String): Prop[User, A] described in the ticket, and clearly mark in the ScalaDocs that it is provided as an IDEA workaround, and will go away after migration to scalameta
Mardo Del Cid
@mardo
yeah, that makes sense