I'm trying to prepend a CSS class to all of the imported CSS using Less, but I can't get it to apply to comma separated selectors.
This is the Less I'm using:
style.less
.myStyle {
#import "imported.less";
}
imported.less
.styleA {}
.styleB {}
.styleC, .styleD {}
The Output
.myStyle .styleA {}
.myStyle .styleB {}
.myStyle .styleC, .styleD {}
Desired Output
.myStyle .styleA {}
.myStyle .styleB {}
.myStyle .styleC, .myStyle .styleD {}
What am I missing?
Related
I'm currently working my way through the Kotlin docs for this section where they cover Derived class initialization order.
For the following snippet...
open class Base(val name: String) {
init { println("Initializing Base") }
open val size: Int = name.length.also { println("Initializing size in Base: $it") }
}
class Derived(
name: String,
val lastName: String
) : Base(name.capitalize().also { println("Argument for Base: $it") }) {
init { println("Initializing Derived") }
override val size: Int =
(super.size + lastName.length).also { println("Initializing size in Derived: $it") }
}
fun main(args: Array<String>) {
println("Constructing Derived(\"hello\", \"world\")")
val d = Derived("hello", "world")
}
when executed it prints this:
Constructing Derived("hello", "world")
Argument for Base: Hello
Initializing Base
Initializing size in Base: 5
Initializing Derived
Initializing size in Derived: 10
My question is, why when override val size: Int = (super.size + lastName.length).also { println("Initializing size in Derived: $it") }
is executed does it not print Initializing size in Base: 5 again?
I would have thought it would print something like this:
Constructing Derived("hello", "world")
Argument for Base: Hello
Initializing Base
Initializing size in Base: 5
Initializing Derived
Initializing size in Base: 5 // Print because .also is called again ?
Initializing size in Derived: 10
You're initializing Base only once.
For that reason you're also initialising size only once.
For that reason you'll execute your also block only once.
Or, to answer your question in a different manner, it doesn't print Initializing size in Base second time, because it doesn't executes name.length.also { println("Initializing size in Base: $it") } second time.
I want to have a common fixture for my tests:
#RunWith(JUnitPlatform::class)
abstract class BaseSpek: Spek({
beforeGroup {println("before")}
afterGroup {println("after")}
})
and now I want to use that spec:
class MySpek: BaseSpek({
it("should xxx") {}
})
but i got compilation error due to no-arg BaseSpek constructor. what's the correct way of achieving what i need?
You can define an extension on Spec that sets up the desired fixture and then apply it in your Speks as follows:
fun Spec.setUpFixture() {
beforeEachTest { println("before") }
afterEachTest { println("after") }
}
#RunWith(JUnitPlatform::class)
class MySpek : Spek({
setUpFixture()
it("should xxx") { println("xxx") }
})
Though this is not exactly what you asked, it still allows flexible code reuse.
UPD: This is a working option with Speks inheritance:
open class BaseSpek(spec: Spec.() -> Unit) : Spek({
beforeEachTest { println("before") }
afterEachTest { println("after") }
spec()
})
#RunWith(JUnitPlatform::class)
class MySpek : BaseSpek({
it("should xxx") { println("xxx") }
})
Basically, do do this, you invert the inheritance direction, so that the child MySpek passes its setup in the form of Spec.() -> Unit to the parent BaseSpek, which adds the setup to what it passes to Spek.
I'm using Spek as test framework, and have troubles when sharing some test-steps for base classes.
I have an abstract base class and two derived classes.
abstract class Base {
abstract fun send()
}
class Foo : Base() {
override fun send() {}
fun anotherFunction() { }
}
class Bar : Base() {
override fun send() {}
fun differentFunction() { }
}
Now my question is: How can I create Speks for those classed, but only define the test for send() once in a base spek?
My first approach was to use SubjectSpek
class BaseSpek : SubjectSpek<Base>({
subject {
// ??? Can't instantiate Base because it is abstract
}
it("test the base") { ... }
})
class FooSpek : SubjectSpek<Foo>({
itBehavesLike(BaseSpek)
it("test anotherFunction") { ... }
})
My second approach was to use inheritance:
abstract class BaseSpek(base: Base) : Spek({
it("test the base") { ... }
})
abstract class FooSpek() : BaseSpek(???)
It seems that none of my approaches works. Any suggestions how to solve this? Should I bring this to the attention of the Spek-Author for possible changes in future releases of Spek?
SubjectSpek is the correct approach.
abstract class BaseSpec: SubjectSpek<Base>({
it("test base") { ... }
})
object FooSpec: BaseSpec<Foo>({
subject { ... }
// ugly for now, until Spek supports #Ignore
itBehavesLike(object: BaseSpec() {})
it("test another") { ... }
})
#Test(groups = { "init" })
public correctVM() {}
#Test(groups = { "init" })
public serverStartedOk() {}
#Test(dependsOnGroups = { "init.* })
public method1() {}
// Above TestNG code
in method1, for the dependsOnGroups regular expression is used. Is it mandatory to use regEx or is it okay to give "init" as all groups are having name as init.
Only if you use the regex will TestNG know that you are not giving an absolute group name but you are indicating a pattern.
So going by your example you would need to mention
#Test(dependsOnGroups = { "init.* })
public method1() {
//code goes here.
}
for TestNG to basically pick up any groups whose names begin with init
Is there a way to specify the return type of a function to be the type of the called object?
e.g.
trait Foo {
fun bar(): <??> /* what to put here? */ {
return this
}
}
class FooClassA : Foo {
fun a() {}
}
class FooClassB : Foo {
fun b() {}
}
// this is the desired effect:
val a = FooClassA().bar() // should be of type FooClassA
a.a() // so this would work
val b = FooClassB().bar() // should be of type FooClassB
b.b() // so this would work
In effect, this would be roughly equivalent to instancetype in Objective-C or Self in Swift.
There's no language feature supporting this, but you can always use recursive generics (which is the pattern many libraries use):
// Define a recursive generic parameter Me
trait Foo<Me: Foo<Me>> {
fun bar(): Me {
// Here we have to cast, because the compiler does not know that Me is the same as this class
return this as Me
}
}
// In subclasses, pass itself to the superclass as an argument:
class FooClassA : Foo<FooClassA> {
fun a() {}
}
class FooClassB : Foo<FooClassB> {
fun b() {}
}
You can return something's own type with extension functions.
interface ExampleInterface
// Everything that implements ExampleInterface will have this method.
fun <T : ExampleInterface> T.doSomething(): T {
return this
}
class ClassA : ExampleInterface {
fun classASpecificMethod() {}
}
class ClassB : ExampleInterface {
fun classBSpecificMethod() {}
}
fun example() {
// doSomething() returns ClassA!
ClassA().doSomething().classASpecificMethod()
// doSomething() returns ClassB!
ClassB().doSomething().classBSpecificMethod()
}
You can use an extension method to achieve the "returns same type" effect. Here's a quick example that shows a base type with multiple type parameters and an extension method that takes a function which operates on an instance of said type:
public abstract class BuilderBase<A, B> {}
public fun <B : BuilderBase<*, *>> B.doIt(): B {
// Do something
return this
}
public class MyBuilder : BuilderBase<Int,String>() {}
public fun demo() {
val b : MyBuilder = MyBuilder().doIt()
}
Since extension methods are resolved statically (at least as of M12), you may need to have the extension delegate the actual implementation to its this should you need type-specific behaviors.
Recursive Type Bound
The pattern you have shown in the question is known as recursive type bound in the JVM world. A recursive type is one that includes a function that uses that type itself as a type for its parameter or its return value. In your example, you are using the same type for the return value by saying return this.
Example
Let's understand this with a simple and real example. We'll replace trait from your example with interface because trait is now deprecated in Kotlin. In this example, the interface VitaminSource returns different implementations of the sources of different vitamins.
In the following interface, you can see that its type parameter has itself as an upper bound. This is why it's known as recursive type bound:
VitaminSource.kt
interface VitaminSource<T: VitaminSource<T>> {
fun getSource(): T {
#Suppress("UNCHECKED_CAST")
return this as T
}
}
We suppress the UNCHECKED_CAST warning because the compiler can't possibly know whether we passed the same class name as a type argument.
Then we extend the interface with concrete implementations:
Carrot.kt
class Carrot : VitaminSource<Carrot> {
fun getVitaminA() = println("Vitamin A")
}
Banana.kt
class Banana : VitaminSource<Banana> {
fun getVitaminB() = println("Vitamin B")
}
While extending the classes, you must make sure to pass the same class to the interface otherwise you'll get ClassCastException at runtime:
class Banana : VitaminSource<Banana> // OK
class Banana : VitaminSource<Carrot> // No compiler error but exception at runtime
Test.kt
fun main() {
val carrot = Carrot().getSource()
carrot.getVitaminA()
val banana = Banana().getSource()
banana.getVitaminB()
}
That's it! Hope that helps.
Depending on the exact use case, scope functions can be a good alternative. For the builder pattern apply seems to be most useful because the context object is this and the result of the scope function is this as well.
Consider this example for a builder of List with a specialized builder subclass:
open class ListBuilder<E> {
// Return type does not matter, could also use Unit and not return anything
// But might be good to avoid that to not force users to use scope functions
fun add(element: E): ListBuilder<E> {
...
return this
}
fun buildList(): List<E> {
...
}
}
class EnhancedListBuilder<E>: ListBuilder<E>() {
fun addTwice(element: E): EnhancedListBuilder<E> {
addNTimes(element, 2)
return this
}
fun addNTimes(element: E, times: Int): EnhancedListBuilder<E> {
repeat(times) {
add(element)
}
return this
}
}
// Usage of builder:
val list = EnhancedListBuilder<String>().apply {
add("a") // Note: This would return only ListBuilder
addTwice("b")
addNTimes("c", 3)
}.buildList()
However, this only works if all methods have this as result. If one of the methods actually creates a new instance, then that instance would be discarded.
This is based on this answer to a similar question.
You can do it also via extension functions.
class Foo
fun <T: Foo>T.someFun(): T {
return this
}
Foo().someFun().someFun()