Given two selectors e.g. "Div.aClass" and ".sub" is there a shorthand in LESS that would mean:
Div.aClass .sub, Div.aClass.sub
i.e. any element that has a sub class but is also either a Div with aClass or a child of such a div ?
I suppose I can use:
Div.aClass {
&.sub, & .sub {
}
}
but a shorter syntax would be nice.
You really do not have much shorter of a syntax available. The most you can eliminate is one &:
Div.aClass {
&.sub, .sub {
prop: test;
}
}
Related
I have read that using !! should generally be avoided.
Is there a way to write the following code in a more elegant way without having to add something like obsolete null checks and duplicated or dead blocks of code?
class A(var field: Thing?) {
fun getField(): Thing {
if (field == null) {
field = Thing()
}
return field!!
}
}
Also I don't understand why the compiler requires the !!-'pray-this-isn't-null-operator' to be satisfied in this scenario.
EDIT: Consider that it is important to me that a potential solution uses lazy initialization if the field is null!
Problem
As Enzokie already mentioned in the comments, another thread could have changed field after the null check. The compiler has no way of knowing that, so you have to tell it.
class A(var field: Thing?) {
fun getField(): Thing {
if (field == null) {
field = Thing()
}
// another thread could have assigned null to field
return field!! // tell the compiler: I am sure that did not happen
}
}
Solution (Eager)
In you particular case it would be a good idea to use a parameter f (you could name it "field" too, but I avoided that for clarity) in the constructor (without val/var) and afterwards assign it to a property field to which you assign either f or a new instance of Thing.
This can be expressed really concise with the Elvis operator :? which takes the left hand side if not null and the right hand side of the expression otherwise. So, in the end field will be of type Thing.
class A(f: Thing?) {
val field = f ?: Thing() // inferred type Thing
}
Solution (Lazy)
Since it was mentioned by gidds, if you need to initialize field lazyly you could do it like this using delegated properties:
class A(f: Thing?) {
val field by lazy {
f ?: Thing() // inferred type Thing
}
}
The call site does not change:
val a = A(null) // field won't be initialized after this line...
a.field // ... but after this
How about this?
class A(field: Thing?) {
private lateinit var field: Thing
init {
field?.let { this.field = it }
}
fun getField(): Thing {
if (!this::field.isInitialized) {
field = Thing()
}
return field
}
}
When you define a field, you actually define a variable plus two accessor methods:
val counter: Integer = 0
It is possible to customize the accessor methods by writing this instead:
val n = 0
val counter: Integer
get() = n++
This will execute the n++ each time you access the counter field, which therefore returns different values on each access. It is uncommon and unexpected but technically possible.
Therefore the Kotlin compiler cannot assume that two accesses to the same field return the same value twice. Usually they do, but it is not guaranteed.
To work around this, you can read the field once by copying it into a local variable:
fun count() {
val counter = counter
println("The counter is $counter, and it is still $counter.")
}
I was thinking to use bootstrap and materialize css but it happen that they have the same class.
If you want to add custom style to an object that already has it's style defined by other css class, sometimes you will have to replace some styles. Here's how to do it:
Firstly, check which class overrides it.
Let's say your markup returns:
<div class="range-specific range"></div>
If your css is defined like that:
.range-specific { foo; }
.range { bar; }
Then the range will win.
If you change it to:
.range-specific.range { foo; }
.range { bar; } `
Then the specific will win.
If you want to hack it even more, do this:
.range-specific.range-specific { foo; }
.range { bar; }
And specific will surely win.
It's even better to do this:
.range { bar; }
.range-specific { foo; }
If u want to override that class you can use nav.app-bg or use !important
Here you can check Overrides of Material-UI
The Kotlin documentation describes how to access this expressions in nested classes.
Is it possible to access this expressions in nested unnamed functions? e.g:
str = "abcde"
str.run {
this.substring(0..2).run {
println("${this} is a substring of ${???}")
}
Just for the sake of answering the question as asked, for situations where this can improve readability, you can use a label:
str.run outer# { // Define a label
this.substring(0..2).run {
println("${this} is a substring of ${this#outer}") // Use the label
}
}
Oftentimes, you'll have implicit labels to use. For example, if the outer call is changed to use a different function name from the inner call, you can access it:
with (str) {
this.substring(0..2).run {
println("${this} is a substring of ${this#with}") // Use the implicit label
}
}
I re-read documentation several times, and I am not getting it. What is the difference between these two? Is it only that with dynamic you don't have to define "bindable" attributes? If so, why would one not just use dynamic always. What are the use cases for one over the other? I am just confused about this and would like somebody if possible to clarify this.
Dynamic Options Binding are only available for custom-attributes, not custom-elements. They are useful when you do not know the name of all the possible properties or when there are too many properties and you are a lazy person like me.
So, instead of declaring several bindable properties
export class MyCustomAttribute {
#bindable prop1;
prop1Changed(newValue, oldValue) { }
#bindable prop2;
prop2Changed(newValue, oldValue) { }
#bindable prop3;
prop3Changed(newValue, oldValue) { }
}
you can decorate de class with #dynamicOptions and use a generic method to detect which property has been set
export class MyCustomAttribute {
propertyChanged(name, newValue, oldValue){
switch(name){
case 'prop1':
//do something
break;
case 'prop2':
//do something
break;
case 'prop3':
//do something
break;
default:
//do something
break;
}
}
}
Why not use #dynamicOptions all the time? Because you would be doing unnecessary conditions most of the time, which is not cool :)
Hope this helps!
I have an enum Foo: String in Swift (therefore not exportable to Objective-C) and I'm trying to create another enum FooObjc in Swift to kinda "wrap" the existent one so that it is 1) available to use in Objective-C and 2) convertable back and forth (Foo <=> FooObjc). The original Foo enum is part of a framework that I don't want to modify. Of course, it's very easy to do what I want if I use a class instead, like this:
#objc public class FooObjc: NSObject {
public private(set) var foo: Foo
#objc public var string: String {
return foo.rawValue
}
#objc public init?(string: NSString) {
guard let foo = Foo(rawValue: string as String) else {
return nil
}
self.foo = foo
}
internal init(foo: Foo) {
self.foo = foo
}
}
(PS: not able to inherit from NSString because the Swift compiler still doesn't accept creating initializers for that class)
Ok, but I definitely don't like this approach because then my Objective-C code will be string-typed. I really want to use an enum instead because after all, that's what it is. This is the least bad working version I could get:
#objc public enum FooObjc: Int, RawRepresentable {
case undefined = -1
case bar
case baz
// omitting many more cases
internal init?(_ foo: Foo?) {
if let foo = foo {
self = fooMapping.filter { $1 == foo }.map { $0.key }.first!
} else {
self = .undefined
}
}
// MARK: - RawRepresentable
public typealias RawValue = String
public init?(rawValue: RawValue) {
let filter = fooMapping.filter { $1?.rawValue == rawValue }
guard filter.count > 0 else {
return nil
}
self = filter.map { $0.key }.first!
}
public var rawValue: RawValue {
switch (self) {
case .undefined: return "undefined"
case .bar: return Foo.bar.rawValue
case .baz: return Foo.baz.rawValue
// omitting many more cases
}
}
}
private let fooMapping: [FooObjc: Foo?] = [
.undefined : nil,
.bar : .bar,
.baz : .baz
// omitting many more cases
]
Notice that:
the fooMapping is useful to avoid one switch-case for each initializer
this undefined case was necessary because in Swift you can have optional enum properties, in Objective-C you can't, so this case will directly map to a Foo? which value is nil.
What worries me here is that I had to write the same cases from the original Foo three times... I'm completely satisfied if I repeat it only twice, but I wasn't able to use the fooMapping in the rawValue property because then I get a cycle between these two.
Note: I'm not sure if this is relevant to the question, but in the original enum, some of the cases have special String attributions, e.g. we have simply case bar but we also have case baz = "something".
So, the question is: does anyone have suggestions to improve this approach or even suggest something completely new that would avoid so much code repetition?
Thank you very much!
What worries me here is that I had to write the same cases from the original Foo three times
Consider an array ["bar", "baz" ...]. By looking at the index of a string in this array and making the necessary adjustments, you can translate from a string to an integer (and thence, via raw value, to a case). By indexing into the array and making the necessary adjustments, you can translate from an integer to a string (and thence, via raw value, to a case). So you will only have to write out the string values once. This eliminates two of your repetitions.
You will still have to write out the case names in the enum declaration, because there's no other way to tell Objective-C the names of the cases. The way to eliminate that repetition, obviously, is to be willing to change the implementation of Foo itself so that it becomes Objective-C-compatible. But you have stated up front that you refuse to do that, so now you must pay the price.