Search Results

Search found 119 results on 5 pages for 'trait'.

Page 2/5 | < Previous Page | 1 2 3 4 5  | Next Page >

  • Self-type mismatch in Scala

    - by Alexey Romanov
    Given this: abstract class ViewPresenterPair { type V <: View type P <: Presenter trait View {self: V => val presenter: P } trait Presenter {self: P => var view: V } } I am trying to define an implementation in this way: case class SensorViewPresenter[T] extends ViewPresenterPair { type V = SensorView[T] type P = SensorPresenter[T] trait SensorView[T] extends View { } class SensorViewImpl[T](val presenter: P) extends SensorView[T] { presenter.view = this } class SensorPresenter[T] extends Presenter { var view: V } } Which gives me the following errors: error: illegal inheritance; self-type SensorViewPresenter.this.SensorView[T] does not conform to SensorViewPresenter.this.View's selftype SensorViewPresenter.this.V trait SensorView[T] extends View { ^ <console>:13: error: type mismatch; found : SensorViewPresenter.this.SensorViewImpl[T] required: SensorViewPresenter.this.V presenter.view = this ^ <console>:16: error: illegal inheritance; self-type SensorViewPresenter.this.SensorPresenter[T] does not conform to SensorViewPresenter.this.Presenter's selftype SensorViewPresenter.this.P class SensorPresenter[T] extends Presenter { ^ I don't understand why. After all, V is just an alias for SensorView[T], and the paths are the same, so how can it not conform?

    Read the article

  • idiomatic property changed notification in scala?

    - by Jeremy Bell
    I'm trying to find a cleaner alternative (that is idiomatic to Scala) to the kind of thing you see with data-binding in WPF/silverlight data-binding - that is, implementing INotifyPropertyChanged. First, some background: In .Net WPF or silverlight applications, you have the concept of two-way data-binding (that is, binding the value of some element of the UI to a .net property of the DataContext in such a way that changes to the UI element affect the property, and vise versa. One way to enable this is to implement the INotifyPropertyChanged interface in your DataContext. Unfortunately, this introduces a lot of boilerplate code for any property you add to the "ModelView" type. Here is how it might look in Scala: trait IDrawable extends INotifyPropertyChanged { protected var drawOrder : Int = 0 def DrawOrder : Int = drawOrder def DrawOrder_=(value : Int) { if(drawOrder != value) { drawOrder = value OnPropertyChanged("DrawOrder") } } protected var visible : Boolean = true def Visible : Boolean = visible def Visible_=(value: Boolean) = { if(visible != value) { visible = value OnPropertyChanged("Visible") } } def Mutate() : Unit = { if(Visible) { DrawOrder += 1 // Should trigger the PropertyChanged "Event" of INotifyPropertyChanged trait } } } For the sake of space, let's assume the INotifyPropertyChanged type is a trait that manages a list of callbacks of type (AnyRef, String) = Unit, and that OnPropertyChanged is a method that invokes all those callbacks, passing "this" as the AnyRef, and the passed-in String). This would just be an event in C#. You can immediately see the problem: that's a ton of boilerplate code for just two properties. I've always wanted to write something like this instead: trait IDrawable { val Visible = new ObservableProperty[Boolean]('Visible, true) val DrawOrder = new ObservableProperty[Int]('DrawOrder, 0) def Mutate() : Unit = { if(Visible) { DrawOrder += 1 // Should trigger the PropertyChanged "Event" of ObservableProperty class } } } I know that I can easily write it like this, if ObservableProperty[T] has Value/Value_= methods (this is the method I'm using now): trait IDrawable { // on a side note, is there some way to get a Symbol representing the Visible field // on the following line, instead of hard-coding it in the ObservableProperty // constructor? val Visible = new ObservableProperty[Boolean]('Visible, true) val DrawOrder = new ObservableProperty[Int]('DrawOrder, 0) def Mutate() : Unit = { if(Visible.Value) { DrawOrder.Value += 1 } } } // given this implementation of ObservableProperty[T] in my library // note: IEvent, Event, and EventArgs are classes in my library for // handling lists of callbacks - they work similarly to events in C# class PropertyChangedEventArgs(val PropertyName: Symbol) extends EventArgs("") class ObservableProperty[T](val PropertyName: Symbol, private var value: T) { protected val propertyChanged = new Event[PropertyChangedEventArgs] def PropertyChanged: IEvent[PropertyChangedEventArgs] = propertyChanged def Value = value; def Value_=(value: T) { if(this.value != value) { this.value = value propertyChanged(this, new PropertyChangedEventArgs(PropertyName)) } } } But is there any way to implement the first version using implicits or some other feature/idiom of Scala to make ObservableProperty instances function as if they were regular "properties" in scala, without needing to call the Value methods? The only other thing I can think of is something like this, which is more verbose than either of the above two versions, but is still less verbose than the original: trait IDrawable { private val visible = new ObservableProperty[Boolean]('Visible, false) def Visible = visible.Value def Visible_=(value: Boolean): Unit = { visible.Value = value } private val drawOrder = new ObservableProperty[Int]('DrawOrder, 0) def DrawOrder = drawOrder.Value def DrawOrder_=(value: Int): Unit = { drawOrder.Value = value } def Mutate() : Unit = { if(Visible) { DrawOrder += 1 } } }

    Read the article

  • How to specialize a type parameterized argument to multiple different types for in Scala?

    - by jmount
    I need a back-check (please). In an article ( http://www.win-vector.com/blog/2010/06/automatic-differentiation-with-scala/ ) I just wrote I stated that it is my belief in Scala that you can not specify a function that takes an argument that is itself a function with an unbound type parameter. What I mean is you can write: def g(f:Array[Double]=>Double,Array[Double]):Double but you can not write something like: def g(f[Y]:Array[Y]=>Double,Array[Double]):Double because Y is not known. The intended use is that inside g() I will specialize fY to multiple different types at different times. You can write: def g[Y](f:Array[Y]=>Double,Array[Double]):Double but then f() is of a single type per call to g() (which is exactly what we do not want). However, you can get all of the equivalent functionality by using a trait extension instead insisting on passing around a function. What I advocated in my article was: 1) Creating a trait that imitates the structure of Scala's Function1 trait. Something like: abstract trait VectorFN { def apply[Y](x:Array[Y]):Y } 2) declaring def g(f:VectorFN,Double):Double (using the trait is the type). This works (people here on StackOverflow helped me find it, and I am happy with it)- but am I mis-representing Scala by missing an even better solution?

    Read the article

  • Valgrind says "stack allocation," I say "heap allocation"

    - by Joel J. Adamson
    Dear Friends, I am trying to trace a segfault with valgrind. I get the following message from valgrind: ==3683== Conditional jump or move depends on uninitialised value(s) ==3683== at 0x4C277C5: sparse_mat_mat_kron (sparse.c:165) ==3683== by 0x4C2706E: rec_mating (rec.c:176) ==3683== by 0x401C1C: age_dep_iterate (age_dep.c:287) ==3683== by 0x4014CB: main (age_dep.c:92) ==3683== Uninitialised value was created by a stack allocation ==3683== at 0x401848: age_dep_init_params (age_dep.c:131) ==3683== ==3683== Conditional jump or move depends on uninitialised value(s) ==3683== at 0x4C277C7: sparse_mat_mat_kron (sparse.c:165) ==3683== by 0x4C2706E: rec_mating (rec.c:176) ==3683== by 0x401C1C: age_dep_iterate (age_dep.c:287) ==3683== by 0x4014CB: main (age_dep.c:92) ==3683== Uninitialised value was created by a stack allocation ==3683== at 0x401848: age_dep_init_params (age_dep.c:131) However, here's the offending line: /* allocate mating table */ age_dep_data->mtable = malloc (age_dep_data->geno * sizeof (double *)); if (age_dep_data->mtable == NULL) error (ENOMEM, ENOMEM, nullmsg, __LINE__); for (int j = 0; j < age_dep_data->geno; j++) { 131=> age_dep_data->mtable[j] = calloc (age_dep_data->geno, sizeof (double)); if (age_dep_data->mtable[j] == NULL) error (ENOMEM, ENOMEM, nullmsg, __LINE__); } What gives? I thought any call to malloc or calloc allocated heap space; there is no other variable allocated here, right? Is it possible there's another allocation going on (the offending stack allocation) that I'm not seeing? You asked to see the code, here goes: /* Copyright 2010 Joel J. Adamson <[email protected]> $Id: age_dep.c 1010 2010-04-21 19:19:16Z joel $ age_dep.c:main file Joel J. Adamson -- http://www.unc.edu/~adamsonj Servedio Lab University of North Carolina at Chapel Hill CB #3280, Coker Hall Chapel Hill, NC 27599-3280 This file is part of an investigation of age-dependent sexual selection. This code is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This software is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with haploid. If not, see <http://www.gnu.org/licenses/>. */ #include "age_dep.h" /* global variables */ extern struct argp age_dep_argp; /* global error message variables */ char * nullmsg = "Null pointer: %i"; /* error message for conversions: */ char * errmsg = "Representation error: %s"; /* precision for formatted output: */ const char prec[] = "%-#9.8f "; const size_t age_max = AGEMAX; /* maximum age of males */ static int keep_going_p = 1; int main (int argc, char ** argv) { /* often used counters: */ int i, j; /* read the command line */ struct age_dep_args age_dep_args = { NULL, NULL, NULL }; argp_parse (&age_dep_argp, argc, argv, 0, 0, &age_dep_args); /* set the parameters here: */ /* initialize an age_dep_params structure, set the members */ age_dep_params_t * params = malloc (sizeof (age_dep_params_t)); if (params == NULL) error (ENOMEM, ENOMEM, nullmsg, __LINE__); age_dep_init_params (params, &age_dep_args); /* initialize frequencies: this initializes a list of pointers to initial frqeuencies, terminated by a NULL pointer*/ params->freqs = age_dep_init (&age_dep_args); params->by = 0.0; /* what range of parameters do we want, and with what stepsize? */ /* we should go from 0 to half-of-theta with a step size of about 0.01 */ double from = 0.0; double to = params->theta / 2.0; double stepsz = 0.01; /* did you think I would spell the whole word? */ unsigned int numparts = floor(to / stepsz); do { #pragma omp parallel for private(i) firstprivate(params) \ shared(stepsz, numparts) for (i = 0; i < numparts; i++) { params->by = i * stepsz; int tries = 0; while (keep_going_p) { /* each time through, modify mfreqs and mating table, then go again */ keep_going_p = age_dep_iterate (params, ++tries); if (keep_going_p == ERANGE) error (ERANGE, ERANGE, "Failure to converge\n"); } fprintf (stdout, "%i iterations\n", tries); } /* for i < numparts */ params->freqs = params->freqs->next; } while (params->freqs->next != NULL); return 0; } inline double age_dep_pmate (double age_dep_t, unsigned int genot, double bp, double ba) { /* the probability of mating between these phenotypes */ /* the female preference depends on whether the female has the preference allele, the strength of preference (parameter bp) and the male phenotype (age_dep_t); if the female lacks the preference allele, then this will return 0, which is not quite accurate; it should return 1 */ return bits_isset (genot, CLOCI)? 1.0 - exp (-bp * age_dep_t) + ba: 1.0; } inline double age_dep_trait (int age, unsigned int genot, double by) { /* return the male trait, a function of the trait locus, age, the age-dependent scaling parameter (bx) and the males condition genotype */ double C; double T; /* get the male's condition genotype */ C = (double) bits_popcount (bits_extract (0, CLOCI, genot)); /* get his trait genotype */ T = bits_isset (genot, CLOCI + 1)? 1.0: 0.0; /* return the trait value */ return T * by * exp (age * C); } int age_dep_iterate (age_dep_params_t * data, unsigned int tries) { /* main driver routine */ /* number of bytes for female frequencies */ size_t geno = data->age_dep_data->geno; size_t genosize = geno * sizeof (double); /* female frequencies are equal to male frequencies at birth (before selection) */ double ffreqs[geno]; if (ffreqs == NULL) error (ENOMEM, ENOMEM, nullmsg, __LINE__); /* do not set! Use memcpy (we need to alter male frequencies (selection) without altering female frequencies) */ memmove (ffreqs, data->freqs->freqs[0], genosize); /* for (int i = 0; i < geno; i++) */ /* ffreqs[i] = data->freqs->freqs[0][i]; */ #ifdef PRMTABLE age_dep_pr_mfreqs (data); #endif /* PRMTABLE */ /* natural selection: */ age_dep_ns (data); /* normalized mating table with new frequencies */ age_dep_norm_mtable (ffreqs, data); #ifdef PRMTABLE age_dep_pr_mtable (data); #endif /* PRMTABLE */ double * newfreqs; /* mutate here */ /* i.e. get the new frequency of 0-year-olds using recombination; */ newfreqs = rec_mating (data->age_dep_data); /* return block */ { if (sim_stop_ck (data->freqs->freqs[0], newfreqs, GENO, TOL) == 0) { /* if we have converged, stop the iterations and handle the data */ age_dep_sim_out (data, stdout); return 0; } else if (tries > MAXTRIES) return ERANGE; else { /* advance generations */ for (int j = age_max - 1; j < 0; j--) memmove (data->freqs->freqs[j], data->freqs->freqs[j-1], genosize); /* advance the first age-class */ memmove (data->freqs->freqs[0], newfreqs, genosize); return 1; } } } void age_dep_ns (age_dep_params_t * data) { /* calculate the new frequency of genotypes given additive fitness and selection coefficient s */ size_t geno = data->age_dep_data->geno; double w[geno]; double wbar, dtheta, ttheta, dcond, tcond; double t, cond; /* fitness parameters */ double mu, nu; mu = data->wparams[0]; nu = data->wparams[1]; /* calculate fitness */ for (int j = 0; j < age_max; j++) { int i; for (i = 0; i < geno; i++) { /* calculate male trait: */ t = age_dep_trait(j, i, data->by); /* calculate condition: */ cond = (double) bits_popcount (bits_extract(0, CLOCI, i)); /* trait-based fitness term */ dtheta = data->theta - t; ttheta = (dtheta * dtheta) / (2.0 * nu * nu); /* condition-based fitness term */ dcond = CLOCI - cond; tcond = (dcond * dcond) / (2.0 * mu * mu); /* calculate male fitness */ w[i] = 1 + exp(-tcond) - exp(-ttheta); } /* calculate mean fitness */ /* as long as we calculate wbar before altering any values of freqs[], we're safe */ wbar = gen_mean (data->freqs->freqs[j], w, geno); for (i = 0; i < geno; i++) data->freqs->freqs[j][i] = (data->freqs->freqs[j][i] * w[i]) / wbar; } } void age_dep_norm_mtable (double * ffreqs, age_dep_params_t * params) { /* this function produces a single mating table that forms the input for recombination () */ /* i is female genotype; j is male genotype; k is male age */ int i,j,k; double norm_denom; double trait; size_t geno = params->age_dep_data->geno; for (i = 0; i < geno; i++) { double norm_mtable[geno]; /* initialize the denominator: */ norm_denom = 0.0; /* find the probability of mating and add it to the denominator */ for (j = 0; j < geno; j++) { /* initialize entry: */ norm_mtable[j] = 0.0; for (k = 0; k < age_max; k++) { trait = age_dep_trait (k, j, params->by); norm_mtable[j] += age_dep_pmate (trait, i, params->bp, params->ba) * (params->freqs->freqs)[k][j]; } norm_denom += norm_mtable[j]; } /* now calculate entry (i,j) */ for (j = 0; j < geno; j++) params->age_dep_data->mtable[i][j] = (ffreqs[i] * norm_mtable[j]) / norm_denom; } } My current suspicion is the array newfreqs: I can't memmove, memcpy or assign a stack variable then hope it will persist, can I? rec_mating() returns double *.

    Read the article

  • Inheritance and type parameters of Traversable

    - by Jesper
    I'm studying the source code of the Scala 2.8 collection classes. I have questions about the hierarchy of scala.collection.Traversable. Look at the following declarations: package scala.collection trait Traversable[+A] extends TraversableLike[A, Traversable[A]] with GenericTraversableTemplate[A, Traversable] trait TraversableLike[+A, +Repr] extends HasNewBuilder[A, Repr] with TraversableOnce[A] package scala.collection.generic trait HasNewBuilder[+A, +Repr] trait GenericTraversableTemplate[+A, +CC[X] <: Traversable[X]] extends HasNewBuilder[A, CC[A] @uncheckedVariance] Question: Why does Traversable extend GenericTraversableTemplate with type parameters [A, Traversable] - why not [A, Traversable[A]]? I tried some experimenting with a small program with the same structure and got a strange error message when I tried to change it to Traversable[A]: error: Traversable[A] takes no type parameters, expected: one I guess that the use of the @uncheckedVariance annotation in GenericTraversableTemplate also has to do with this? (That seems like a kind of potentially unsafe hack to force things to work...). Question: When you look at the hierarchy, you see that Traversable inherits HasNewBuilder twice (once via TraversableLike and once via GenericTraversableTemplate), but with slightly different type parameters. How does this work exactly? Why don't the different type parameters cause an error?

    Read the article

  • Scala: Correcting type inference of representation type over if statement

    - by drhagen
    This is a follow-up to two questions on representation types, which are type parameters of a trait designed to represent the type underlying a bounded type member (or something like that). I've had success creating instances of classes, e.g ConcreteGarage, that have instances cars of bounded type members CarType. trait Garage { type CarType <: Car[CarType] def cars: Seq[CarType] def copy(cars: Seq[CarType]): Garage def refuel(car: CarType, fuel: CarType#FuelType): Garage = copy( cars.map { case `car` => car.refuel(fuel) case other => other }) } class ConcreteGarage[C <: Car[C]](val cars: Seq[C]) extends Garage { type CarType = C def copy(cars: Seq[C]) = new ConcreteGarage(cars) } trait Car[C <: Car[C]] { type FuelType <: Fuel def fuel: FuelType def copy(fuel: C#FuelType): C def refuel(fuel: C#FuelType): C = copy(fuel) } class Ferrari(val fuel: Benzin) extends Car[Ferrari] { type FuelType = Benzin def copy(fuel: Benzin) = new Ferrari(fuel) } class Mustang(val fuel: Benzin) extends Car[Mustang] { type FuelType = Benzin def copy(fuel: Benzin) = new Mustang(fuel) } trait Fuel case class Benzin() extends Fuel I can easily create instances of Cars like Ferraris and Mustangs and put them into a ConcreteGarage, as long as it's simple: val newFerrari = new Ferrari(Benzin()) val newMustang = new Mustang(Benzin()) val ferrariGarage = new ConcreteGarage(Seq(newFerrari)) val mustangGarage = new ConcreteGarage(Seq(newMustang)) However, if I merely return one or the other, based on a flag, and try to put the result into a garage, it fails: val likesFord = true val new_car = if (likesFord) newFerrari else newMustang val switchedGarage = new ConcreteGarage(Seq(new_car)) // Fails here The switch alone works fine, it is the call to ConcreteGarage constructor that fails with the rather mystical error: error: inferred type arguments [this.Car[_ >: this.Ferrari with this.Mustang <: this.Car[_ >: this.Ferrari with this.Mustang <: ScalaObject]{def fuel: this.Benzin; type FuelType<: this.Benzin}]{def fuel: this.Benzin; type FuelType<: this.Benzin}] do not conform to class ConcreteGarage's type parameter bounds [C <: this.Car[C]] val switchedGarage = new ConcreteGarage(Seq(new_car)) // Fails here ^ I have tried putting those magic [C <: Car[C]] representation type parameters everywhere, but without success in finding the magic spot.

    Read the article

  • Foiled by path-dependent types

    - by Ladlestein
    I'm having trouble using, in one trait, a Parser returned from a method in another trait. The compiler complains of a type mismatch and it appears to me that the problem is due to the path-dependent class. I'm not sure how to get what I want. trait Outerparser extends RegexParsers { def inner: Innerparser def quoted[T](something: Parser[T]) = "\"" ~> something <~ "\"" def quotedNumber = quoted(inner.number) // Compile error def quotedLocalNumber = quoted(number) // Compiles just fine def number: Parser[Int] = ("""[1-9][0-9]*"""r) ^^ {str => str.toInt} } trait Innerparser extends RegexParsers { def number: Parser[Int] = ("""[1-9][0-9]*"""r) ^^ {str => str.toInt} } And the error: [error] /Path/to/MyParser.scala:6: type mismatch [error] found : minerals.Innerparser#Parser[Int] [error] required: Outerparser.this.Parser[?] [error] def quotedNumber = quoted(inner.number) I sort-of get the idea: each "something" method is defining a Parser type whose path is specific to the enclosing class (Outerparser or Innerparser). The "quoted" method of Outerparser expects an an instance of type Outerparser.this.Parser but is getting Innerparser#Parser. I like to be able to use quoted with a parser obtained from this class or some other class. How can I do that?

    Read the article

  • Composing actors

    - by Brian Heylin
    I've implemented a Listenable/Listener trait that can be added to Actors. I'm wondering if it's possible to attach this style of trait to an actor without it having to explicitly call the listenerHandler method? Also I was expecting to find this functionality in the Akka library. Am I missing something or is there some reason that Akka would not not include this? trait Listenable { this: Actor => private var listeners: List[Actor] = Nil protected def listenerHandler: PartialFunction[Any, Unit] = { case AddListener(who) => listeners = who :: listeners } protected def notifyListeners(event: Any) = { listeners.foreach(_.send(event)) } } class SomeActor extends Actor with Listenable { def receive = listenerHandler orElse { case Start => notifyListeners(Started()) case Stop => notifyListeners(Stopped()) } }

    Read the article

  • Is there a language or design pattern that allows the *removal* of object behavior or properties in a class hierarchy?

    - by Sebastien Diot
    A well-know shortcoming of traditional class hierarchies is that they are bad when it comes to model the real world. As an example, trying to represent animals species with classes. There are actually several problems when doing that, but one that I never saw a solution to is when a sub-class "looses" a behavior or properties that was defined in a super-class, like a penguin not being able to fly (there are probably better examples, but that's the first one that comes to my mind, having seen "Madagascar 2" recently). On the one hand, you don't want to define for every property and behavior some flag that specifies if it is at all present, and check it every time before accessing that behavior or property. You would just like to say that birds can fly, simply and clearly, in the Bird class. But then it would be nice if one could define "exceptions" afterward, without having to use some horrible hacks everywhere. This often happens when a system has been productive for a while. You suddenly find an "exception" that doesn't fit in the original design at all, and you don't want to change a large portion of your code to accommodate it. So, is there some language or design patterns that can cleanly handle this problem, without requiring major changes to the "super-class", and all the code that uses it? Even if a solution only handle a specific case, several solutions might together form a complete strategy. [EDIT] Forgot about the Liskov Substitution Principle. That is why you can't do it. Assuming you define "traits/interfaces" for all major "feature groups", you can freely implement traits in different branches of the hierarchy, like the Flying trait could be implemented by Birds, and some special kind of squirrels and fish. So my question could amount to "How could I un-implement a trait?" If your super-class is a Java Serializable, you have to be one too, even if there is no way for you to serialize your state, for example if you contained a "Socket". So one way to do it is to always define all your traits in pair from the start: Flying and NotFlying (which would throw UnsupportedOperationExceiption, if not checked against). The Not-trait would not define any new interface, and could be simply checked for. Sounds like a "cheap" solution, in particular if used from the start.

    Read the article

  • Step by Step / Deep explain: The Power of (Co)Yoneda (preferably in scala) through Coroutines

    - by Mzk
    some background code /** FunctorStr: ? F[-]. (? A B. (A -> B) -> F[A] -> F[B]) */ trait FunctorStr[F[_]] { self => def map[A, B](f: A => B): F[A] => F[B] } trait Yoneda[F[_], A] { yo => def apply[B](f: A => B): F[B] def run: F[A] = yo(x => x) def map[B](f: A => B): Yoneda[F, B] = new Yoneda[F, B] { def apply[X](g: B => X) = yo(f andThen g) } } object Yoneda { implicit def yonedafunctor[F[_]]: FunctorStr[({ type l[x] = Yoneda[F, x] })#l] = new FunctorStr[({ type l[x] = Yoneda[F, x] })#l] { def map[A, B](f: A => B): Yoneda[F, A] => Yoneda[F, B] = _ map f } def apply[F[_]: FunctorStr, X](x: F[X]): Yoneda[F, X] = new Yoneda[F, X] { def apply[Y](f: X => Y) = Functor[F].map(f) apply x } } trait Coyoneda[F[_], A] { co => type I def fi: F[I] def k: I => A final def map[B](f: A => B): Coyoneda.Aux[F, B, I] = Coyoneda(fi)(f compose k) } object Coyoneda { type Aux[F[_], A, B] = Coyoneda[F, A] { type I = B } def apply[F[_], B, A](x: F[B])(f: B => A): Aux[F, A, B] = new Coyoneda[F, A] { type I = B val fi = x val k = f } implicit def coyonedaFunctor[F[_]]: FunctorStr[({ type l[x] = Coyoneda[F, x] })#l] = new CoyonedaFunctor[F] {} trait CoyonedaFunctor[F[_]] extends FunctorStr[({type l[x] = Coyoneda[F, x]})#l] { override def map[A, B](f: A => B): Coyoneda[F, A] => Coyoneda[F, B] = x => apply(x.fi)(f compose x.k) } def liftCoyoneda[T[_], A](x: T[A]): Coyoneda[T, A] = apply(x)(a => a) } Now I thought I understood yoneda and coyoneda a bit just from the types – i.e. that they quantify / abstract over map fixed in some type constructor F and some type a, to any type B returning F[B] or (Co)Yoneda[F, B]. Thus providing map fusion for free (? is this kind of like a cut rule for map ?). But I see that Coyoneda is a functor for any type constructor F regardless of F being a Functor, and that I don't fully grasp. Now I'm in a situation where I'm trying to define a Coroutine type, (I'm looking at https://www.fpcomplete.com/school/to-infinity-and-beyond/pick-of-the-week/coroutines-for-streaming/part-2-coroutines for the types to get started with) case class Coroutine[S[_], M[_], R](resume: M[CoroutineState[S, M, R]]) sealed trait CoroutineState[S[_], M[_], R] object CoroutineState { case class Run[S[_], M[_], R](x: S[Coroutine[S, M, R]]) extends CoroutineState[S, M, R] case class Done[R](x: R) extends CoroutineState[Nothing, Nothing, R] class CoroutineStateFunctor[S[_], M[_]](F: FunctorStr[S]) extends FunctorStr[({ type l[x] = CoroutineState[S, M, x]})#l] { override def map[A, B](f : A => B) : CoroutineState[S, M, A] => CoroutineState[S, M, B] = { ??? } } } and I think that if I understood Coyoneda better I could leverage it to make S & M type constructors functors way easy, plus I see Coyoneda potentially playing a role in defining recursion schemes as the functor requirement is pervasive. So how could I use coyoneda to make type constructors functors like for example coroutine state? or something like a Pause functor ?

    Read the article

  • Unpacking tuple types in Scala

    - by jpalecek
    I was just wondering, can I decompose a tuple type into its components' types in Scala? I mean, something like this trait Container { type Element } trait AssociativeContainer extends Container { type Element <: (Unit, Unit) def get(x : Element#First) : Element#Second }

    Read the article

  • Improving MVP in Scala

    - by Alexey Romanov
    The classical strongly typed MVP pattern looks like this in Scala: trait IView { } trait Presenter[View <: IView] { // or have it as an abstract type member val view : View } case class View1(...) extends IView { ... } case object Presenter1 extends Presenter[View1] { val view = View1(...) } Now, I wonder if there is any nice way to improve on it which I am missing...

    Read the article

  • A View from the Top – Jan Ackerman (VP APAC Recruiting)

    - by user769227
    This week, Headhunt Magazine in Singapore, took the opportunity to publish an interview with Jan Ackerman who is Vice President for Recruitment for Asia Pacific here at Oracle. The link to the online interview can be found here. Below is the interview in full that was published in Headhunt Magazine.  A View from the Top – Jan Ackerman Written by HeadHunt on August 16, 2012 · Leave a Comment By Susheela Menon Jan Ackerman is the Vice President for Recruiting in Asia Pacific and Japan at Oracle. Which particular personal trait do you attribute your professional success to? Perseverance has been the most important trait that has attributed to my professional success. Endurance and perseverance combined to win in the end has always been a great credo. I find that this trait carries through in my professional as well as my personal life. I enjoy sport fishing and find that perseverance with a great deal of patience in this hobby is critical to the overall enjoyment and success in this sporting activity. In the same way, this doggedness – steadfastness with persistence – and tenacity toward an unyielding course of action has served me well in reaching goals and thus greater success. What’s the biggest challenge you have faced in your career so far? I have to constantly keep pace with ever changing technology in my career. The industry changes rapidly and requires me to stay on top of the latest trends and advancements. Outside of work, I like to develop software as a hobby and in order to ensure that what I am developing will meet what the business needs, I have to continually innovate and stay current on the latest trends in the industry to deliver a solution that will delight the end- user. Best career advice you have ever received. Always be forthright and honest with your customers and peers; mixed with a “Can Do” attitude, a great and fulfilling career can be yours to have and hold. What makes Oracle a great place to be in? The freedom to innovate and pave new avenues of success is one of the greatest things about working here at Oracle. We are always looking to grow and improve our business for our customers and we are always adapting to present and future industry demands. This means we are always looking to change, to perform better and to do things differently. All these create a culture and spirit of innovation and success. What motivates you to be in the HR sector? I really like working with and helping people. HR is all about “the people” in the organisation, and staying focused every day on making things better for the Oracle team gives me a great deal of happiness. Describe your leadership style. I am very direct and goal- oriented. I provide ideas and guidance and then give the team all the freedom they need to reach a successful outcome. I can also be a very “roll up your sleeves” kind of manager when the task needs a bit of a push. What’s the biggest business challenge you see in your industry right now? The ability to keep pace with all the convergence in the industry and to continue to stay focused on delivering top talent to serve Oracle’s customers well. Our unique Recruiting Model has served us well in meeting these needs. We are well-placed in this goal and look forward to maintain Oracle’s leadership role in the industry.

    Read the article

  • Moose read-only Attribute Traits and how to set them?

    - by Evan Carroll
    How do I set a Moose read only attribute trait? package AttrTrait; use Moose::Role; has 'ext' => ( isa => 'Str', is => 'ro' ); package Class; has 'foo' => ( isa => 'Str', is => 'ro', traits => [qw/AttrTrait/] ); package main; my $c = Class->new( foo => 'ok' ); $c->meta->get_attribute('foo')->ext('die') # ro attr trait What is the purpose of Read Only attribute traits if you can't set it in the constructor or in runtime? Is there something I'm missing in Moose::Meta::Attribute? Is there a way to set it using meta? $c->meta->get_attr('ext')->set_value('foo') # doesn't work either (attribute trait provided not class provided method)

    Read the article

  • Using Scala structural types with abstract types

    - by Joshua Hartman
    I'm trying to define a structural type defining anything that has an "add" method (for instance, a java collection or a java map). Using this, I want to define a few higher order functions that operate on a certain collection object GenericTypes { type GenericCollection[T] = { def add(value: T): java.lang.Boolean} } import GenericTypes._ trait HigherOrderFunctions[T, CollectionType[X] <: GenericCollection[X]] { def map[V](fn: (T) => V): CollectionType[V] .... } class RichJList[T](list: List[T]) extends HigherOrderFunctions[T, java.util.List] This does not compile with the following error error: Parameter type in structural refinement may not refer to abstract type defined outside that same refinement I tried removing the parameter on GenericCollection and putting it on the method: object GenericTypes { type GenericCollection = { def add[T](value: T): java.lang.Boolean} } import GenericTypes._ trait HigherOrderFunctions[T, CollectionType[X] <: GenericCollection] class RichJList[T](list: List[T]) extends HigherOrderFunctions[T, java.util.List] but I get another error: error: type arguments [T,java.util.List] do not conform to trait HigherOrderFunctions's type parameter bounds [T,CollectionType[X] <: org.scala_tools.javautils.j2s.GenericTypes.GenericCollection] Can anyone give me some advice on how to use structural typing with abstract typed parameters in Scala? Or how to achieve what I'm looking to accomplish? Thanks so much!

    Read the article

  • Scala implicit dynamic casting

    - by weakwire
    I whould like to create a scala Views helper for Android Using this combination of trait and class class ScalaView(view: View) { def onClick(action: View => Any) = view.setOnClickListener(new OnClickListener { def onClick(view: View) { action(view) } }) } trait ScalaViewTrait { implicit def view2ScalaView(view: View) = new ScalaView(view) } I'm able to write onClick() like so class MainActivity extends Activity with ScalaViewTrait { //.... val textView = new TextView(this) textView.onClick(v => v.asInstanceOf[TextView] setText ("asdas")) } My concern is that i want to avoid casting v to TextView v will always be TextView if is applied to a TextView LinearLayout if applied to LinearLayout and so on. Is there any way that v gets dynamic casted to whatever view is applied? Just started with Scala and i need your help with this. UPDATE With the help of generics the above get's like this class ScalaView[T](view: View) { def onClick(action: T => Any) = view.setOnClickListener(new OnClickListener { def onClick(view: View) { action(view.asInstanceOf[T]) } }) } trait ScalaViewTrait { implicit def view2ScalaView[T](view: View) = new ScalaView[T](view) } i can write onClick like this view2ScalaView[TextView](textView) .onClick(v => v.setText("asdas")) but is obvious that i don't have any help from explicit and i moved the problem instead or removing it

    Read the article

  • The idea of functionN in Scala / Functionaljava

    - by Luke Murphy
    From brain driven development It turns out, that every Function you’ll ever define in Scala, will become an instance of an Implementation which will feature a certain Function Trait. There is a whole bunch of that Function Traits, ranging from Function1 up to Function22. Since Functions are Objects in Scala and Scala is a statically typed language, it has to provide an appropriate type for every Function which comes with a different number of arguments. If you define a Function with two arguments, the compiler picks Function2 as the underlying type. Also, from Michael Froh's blog You need to make FunctionN classes for each number of parameters that you want? Yes, but you define the classes once and then you use them forever, or ideally they're already defined in a library (e.g. Functional Java defines classes F, F2, ..., F8, and the Scala standard library defines classes Function1, ..., Function22) So we have a list of function traits (Scala), and a list of interfaces (Functional-java) to enable us to have first class funtions. I am trying to understand exactly why this is the case. I know, in Java for example, when I write a method say, public int add(int a, int b){ return a + b; } That I cannot go ahead and write add(3,4,5); ( error would be something like : method add cannot be applied to give types ) We simply have to define an interface/trait for functions with different parameters, because of static typing?

    Read the article

  • How to access "overridden" inner class in Scala?

    - by doom2.wad
    I have two traits, one extending the other, each with an inner class, one extending the other, with the same names: trait A { class X { def x() = doSomething() } } trait B extends A { class X extends super.X { override def x() = doSomethingElse() } } class C extends B { val x = new X() // here B.X is instantiated val y = new A.X() // does not compile val z = new A.this.X() // does not compile } How do I access A.X class in the C class's body? Renaming B.X not to hide A.X is not a preferred way. To make things a bit complicated, in the situation I have encountered this problem the traits have type parameters (not shown in this example).

    Read the article

  • Default type-parametrized function literal class parameter

    - by doom2.wad
    Is this an intended behavior or is it a bug? Consider the following trait (be it a class, doesn't matter): trait P[T] { class Inner(val f: T => Unit = _ => println("nope")) } This is what I would have expected: scala> val p = new P[Int] { | val inner = new Inner | } p: java.lang.Object with P[Int]{def inner: this.Inner} = $anon$1@12192a9 scala> p.inner.f(5) nope But this? scala> val p = new P[Int] { | val inner = new Inner() { | println("some primary constructor code in here") | } | } <console>:6: error: type mismatch; found : (T) => Unit required: (Int) => Unit val inner = new Inner() { ^

    Read the article

  • Adding two Set[Any]

    - by Alex Boisvert
    Adding two Set[Int] works: Welcome to Scala version 2.8.1.final (Java HotSpot(TM) Server VM, Java 1.6.0_23). Type in expressions to have them evaluated. Type :help for more information. scala> Set(1,2,3) ++ Set(4,5,6) res0: scala.collection.immutable.Set[Int] = Set(4, 5, 6, 1, 2, 3) But adding two Set[Any] doesn't: scala> Set[Any](1,2,3) ++ Set[Any](4,5,6) <console>:6: error: ambiguous reference to overloaded definition, both method ++ in trait Addable of type (xs: scala.collection.TraversableOnce[Any])scala.collection.immutable.Set[Any] and method ++ in trait TraversableLike of type [B >: Any,That](that: scala.collection.TraversableOnce[B])(implicit bf: scala.collection.generic.CanBuildFrom[scala.collection.immutable.Set[Any],B,That])That match argument types (scala.collection.immutable.Set[Any]) Set[Any](1,2,3) ++ Set[Any](4,5,6) ^ Any suggestion to work around this error?

    Read the article

  • logging in scala

    - by IttayD
    In Java, the standard idiom for logging is to create a static variable for a logger object and use that in the various methods. In Scala, it looks like the idiom is to create a Logging trait with a logger member and mixin the trait in concrete classes. This means that each time an object is created it calls the logging framework to get a logger and also the object is bigger due to the additional reference. Is there an alternative that allows the ease of use of "with Logging" while still using a per-class logger instance? EDIT: My question is not about how one can write a logging framework in Scala, but rather how to use an existing one (log4j) without incurring an overhead of performance (getting a reference for each instance) or code complexity. Also, yes, I want to use log4j, simply because I'll use 3rd party libraries written in Java that are likely to use log4j.

    Read the article

  • Implicit parameter in Scalaz

    - by Thomas Jung
    I try to find out why the call Ø in scalaz.ListW.<^> works def <^>[B: Zero](f: NonEmptyList[A] => B): B = value match { case Nil => Ø case h :: t => f(Scalaz.nel(h, t)) } My minimal theory is: trait X[T]{ def y : T } object X{ implicit object IntX extends X[Int]{ def y = 42 } implicit object StringX extends X[String]{ def y = "y" } } trait Xs{ def ys[T](implicit x : X[T]) = x.y } class A extends Xs{ def z[B](implicit x : X[B]) : B = ys //the call Ø } Which produces: import X._ scala> new A().z[Int] res0: Int = 42 scala> new A().z[String] res1: String = y Is this valid? Can I achieve the same result with fewer steps?

    Read the article

  • Scala: Mixing traits with private fields

    - by Vilius Normantas
    It's not much of a question, it's rather my excitement that it's possible at all! I wrote this little example just to prove the opposite - I expected either a compiler error or one of the values (111 or 222, I wasn't sure). scala> trait T1 { private val v = 111; def getValueT1 = v } scala> trait T2 { private val v = 222; def getValueT2 = v } scala> class T12 extends T1 with T2 scala> val t = new T12 scala> t.getValueT1 res9: Int = 111 scala> t.getValueT2 res10: Int = 222 Why doesn't the v get overridden? Off course this works only as long as vs are private, but still.

    Read the article

  • Example of contravariance

    - by Misha
    I am thinking of the following example to illustrate why contravariance is useful. Let's consider a GUI framework with Widgets, Events, and Event Listeners. abstract class Event; class KeyEvent extends Event class MouseEvent extends Event trait EventListener[-Event] { def listen(e:Event) } Let Widgets define the following methods: def addKeyEventListener(listener:EventListener[KeyEvent]) def addMouseEventListener(listener:EventListener[MouseEvent]) These methods accept only "specific" event listeners, which is fine. However I would like to define also "kitchen-sink" listeners, which listen to all events, and pass such listeners to the "add listener" methods above. For instance, I would like to define LogEventListener to log all incoming events class LogEventListener extends EventListener[Event] { def listen(e:Event) { log(event) } } Since the trait EventListener is contravariant in Event we can pass LogEventListener to all those "add listener" methods without losing their type safety. Does it make sense ?

    Read the article

  • C++ Types Impossible to Name

    - by Kirakun
    While reading Wikipedia's page on decltype, I was curious about the statement, Its [decltype's] primary intended use is in generic programming, where it is often difficult, or even impossible, to name types that depend on template parameters. While I can understand the difficulty part of that statement, what is an example where there is a need to name a type that cannot be named under C++03? EDIT: My point is that since everything in C++ has a declaration of types. Why would there ever be a case where it is impossible to name a type? Furthermore, aren't trait classes designed to yield type informations? Could trait classes be an alternative to decltype?

    Read the article

< Previous Page | 1 2 3 4 5  | Next Page >