traits | 易学教程

Is this the correct way of translating Java interface into Scala?

阅读更多关于 Is this the correct way of translating Java interface into Scala?

I am starting to learn Scala and I will do a simple cross compiler. I will support a small set of instructions like print. Note: the code snippets are not tested or compiled. Here is what I would do in JAVA. public interface Compiler{ String getPrintInstruction(); } public class JavaCompiler implements Compiler{ public String getPrintInstruction(){ return "System.out.print(arg0);" } } public class ScalaCompiler implements Compiler{ public String getPrintInstruction(){ return "print(arg0);" } } Is the snippet below the correct "Scala way "? trait Compiler { var printInstruction: String } class

When is it appropriate to mark a trait as unsafe, as opposed to marking all the functions in the trait as unsafe?

阅读更多关于 When is it appropriate to mark a trait as unsafe, as opposed to marking all the functions in the trait as unsafe?

问题 Saying the same thing in code, when would I pick either of the following examples? unsafe trait MyCoolTrait { fn method(&self) -> u8; } trait MyCoolTrait { unsafe fn method(&self) -> u8; } The opt-in builtin traits (OIBIT) RFC states: An unsafe trait is a trait that is unsafe to implement, because it represents some kind of trusted assertion. Note that unsafe traits are perfectly safe to use. Send and Share ( note: now called Sync ) are examples of unsafe traits: implementing these traits is

Ways to achieve effective Java traits?

阅读更多关于 Ways to achieve effective Java traits?

问题 Please let me know if this is inappropriate as formulated (in particular whether Programmers.SE or something would be better for the question.) Alright. So I've got a number of 'traits' that I'm currently expressing as interfaces. Let's call them "updatable" and "destructible". Expressing them as interfaces has the downside that I can't share behavior between all "destructible" components; on the other hand, expressing these as abstract classes mean I can't mix and match without explicitly

Do self: T => and this: T => have the same meaning when defining a trait?

阅读更多关于 Do self: T => and this: T => have the same meaning when defining a trait?

问题 It seems I can use self or this for referring to the mixed-in instance or rather to constraint the mixed-in instance. For instance, are those equivalent? scala> trait A { self: List[_] => } defined trait A scala> trait B { this: List[_] => } defined trait B Is this just a convention, or using something different than this provide some benefits? 回答1: Using a name other than "this" can be useful where you have member types which refer to the enclosing instance. For example, trait Outer { self =

How Scala Traits behave?

阅读更多关于 How Scala Traits behave?

问题 I created this small Scala example for understand better traits. trait Writer { def write(value: Int): Unit = { print("Writer") } } trait Hdd extends Writer { override def write(value: Int): Unit = { print("Hdd") } } trait File extends Writer { override def write(value: Int): Unit = { print("File") } } class TestClass extends App { (1) val myWriter = new Writer with Hdd // This line looks fine (2) val myNewWriter = new Writer // This line fail } In my understanding, it's not possible to

Trait runtime type of type parameter through TypeTag when used with Existential type in Scala

阅读更多关于 Trait runtime type of type parameter through TypeTag when used with Existential type in Scala

I have trait with type parameter. To get the runtime type I use TypeTag . However, when this trait (and its classes) are used with existential type in a Collection, e.g. List or Map , TypeTag is "lost". Here is an example of standard way to use Type Tag: scala> import scala.reflect.runtime.universe._ import scala.reflect.runtime.universe._ scala> trait Animal[T] { | def typeT()(implicit t: TypeTag[T]) = t.tpe | } defined trait Animal scala> scala> class Dog extends Animal[Int] defined class Dog scala> class Cat extends Animal[String] defined class Cat scala> scala> val dog = new Dog dog: Dog =

Implicit Conversions on Generic Trait

阅读更多关于 Implicit Conversions on Generic Trait

I am implementing a datastructure and want the user to be able to use any type as key as long as he provides a suitable key type wrapping it. I have a trait for this key type. The idea is to have implicit conversions from base to key type and the other way round to (virtually) just use the base type. The trait looks like this: trait Key[T] extends Ordered[Key[T]] { def toBase : T // Further stuff needed for datastructure... } object Key { implicit def key2base[T](k : Key[T]) : T = k.toBase } Call site code could look like this: def foo[K <% Key[K]]( bar : Seq[K] ) = bar.sorted(0) Plan is that

Codeigniter 3: How to use composer packages? (Twilio SDK)

阅读更多关于 Codeigniter 3: How to use composer packages? (Twilio SDK)

问题 What I did so far: I am pretty familiar with CI, but new to composer and the twilio SDK. Reading some tutorials and docs I managed to install composer and the twilio package. However the /vendor folder is parallel to my CI installation: /var/www/html/ - application - system - vendor I have therefore edited the config.php setting the path like this: $config['composer_autoload'] = '/var/www/html/vendor/autoload.php'; In my controller tried to use the SDK as documented in the Twilio SDK: <?php

Disabling a FactoryGirl association within a trait

阅读更多关于 Disabling a FactoryGirl association within a trait

In a Rails app, I'm using FactoryGirl to define a general factory plus several more specific traits. The general case and all but one of the traits have a particular association, but I'd like to define a trait where that association is not created/built. I can use an after callback to set the association's id to nil , but this doesn't stop the association record from being created in the first place. Is there a way in a trait definition to completely disable the creation/building of an association that has been defined for the factory the trait belongs to? For example: FactoryGirl.define do

SFINAE issue in creating an “is_iterable” trait - is this a gcc bug?

阅读更多关于 SFINAE issue in creating an “is_iterable” trait - is this a gcc bug?

问题 The following code attempts (without using c++11) to create a trait for identifying whether a type is iterable in STL fashion : #include <iostream> #include <vector> template<typename C> struct IsIterable { typedef char true_type; typedef long false_type; template<class T> static true_type is_beg_iterable( typename T::const_iterator = C().begin()); template<class T> static false_type is_beg_iterable(...); enum { value = sizeof(is_beg_iterable<C>()) == sizeof(true_type) }; }; int main() { std: