|
View:
New views
4 Messages
—
Rating Filter:
Alert me
|
|
|
pattern matching with type parametersHi all,
Is it possible to pattern match case classes with type parameters. E.g. if I have case class Msg[T]() Can I have a match like this: receive { case Msg[T] => ... some code that uses the type information T ... } I know that the code above does not compile, but is there a way to mimic its meaning? Thanks, Petar |
|
|
Re: [scala] pattern matching with type parametersscala> case class Msg[T](implicit val manifest: scala.reflect.Manifest[T])
defined class Msg scala> case class StrMsg(s: String) extends Msg[String]; defined class StrMsg scala> (StrMsg("3"):Msg[String]) match { case m@ Msg() => println(m.manifest) } java.lang.String Not perfect, but it's a start. -- David On Thu, May 28, 2009 at 4:24 PM, PetarM <petarm@...> wrote: > > Hi all, > > Is it possible to pattern match case classes with type parameters. E.g. if I > have > > case class Msg[T]() > > Can I have a match like this: > > receive { > case Msg[T] => ... some code that uses the type information T ... > } > > I know that the code above does not compile, but is there a way to mimic its > meaning? > > Thanks, > Petar > > > -- > View this message in context: http://www.nabble.com/pattern-matching-with-type-parameters-tp23771884p23771884.html > Sent from the Scala mailing list archive at Nabble.com. > > |
|
|
Re: [scala] pattern matching with type parameters(Moving to -debate since I'm asking controversial question...)
It seems manifest are quite important for Why not have one scala.reflect.Manifest automatically added to all Scala classes for each type parameter and type member? Would this be such a memory or performance burden? And if it is, maybe we could have an annotation to disable the feature. On Thu, May 28, 2009 at 4:29 PM, David Hall <dlwh@...> wrote: scala> case class Msg[T](implicit val manifest: scala.reflect.Manifest[T]) |
|
|
Re: [scala] pattern matching with type parameters(Damn these send buttons that triggers by themselves!! Here's what I was writing...)
It seems manifests are quite important and generally useful to support good OO practices. Why not have one scala.reflect.Manifest automatically added to all Scala classes for each type parameter and type member? Would this be such a memory or performance burden? And if it is, maybe we could have an annotation to disable the feature? I'm feeling we're going down the boilerplate road with this... maybe when manifests are fully fleshed out and no longer experimental they could be tightly integrated in the language? alex On Thu, May 28, 2009 at 4:37 PM, Alex Boisvert <boisvert@...> wrote: (Moving to -debate since I'm asking controversial question...) |
| Free embeddable forum powered by Nabble | Forum Help |