ursus
12/17/2018, 4:12 PMinterface FooProvider {
fun <T> getFoo() : T <--- works
val <T> foo: T <--- doesnt
}
diesieben07
12/17/2018, 4:14 PMShawn
12/17/2018, 4:14 PMursus
12/17/2018, 4:17 PMfun <T> findViewById(): T
diesieben07
12/17/2018, 4:17 PMursus
12/17/2018, 4:18 PMdiesieben07
12/17/2018, 4:22 PMursus
12/17/2018, 4:22 PMAlan Evans
12/17/2018, 4:22 PMinterface FooProvider<T> {
fun getFoo(): T// <--- works
val foo2: T //<--- works
}
ursus
12/17/2018, 4:23 PMShawn
12/17/2018, 4:23 PMursus
12/17/2018, 4:24 PMRuckus
12/17/2018, 4:26 PMursus
12/17/2018, 4:27 PMShawn
12/17/2018, 4:29 PMval
ursus
12/17/2018, 4:29 PMShawn
12/17/2018, 4:29 PMursus
12/17/2018, 4:30 PMShawn
12/17/2018, 4:30 PMursus
12/17/2018, 4:31 PMShawn
12/17/2018, 4:31 PMursus
12/17/2018, 4:33 PMRuckus
12/17/2018, 4:34 PMShawn
12/17/2018, 4:34 PMursus
12/17/2018, 4:35 PMRuckus
12/17/2018, 4:36 PMursus
12/17/2018, 4:37 PMoverride val appComponent: AppComponent
get() = ...
in implementing classShawn
12/17/2018, 4:38 PMval
to accomplish what you’re trying to do - that fact is not a contradiction of the validity of having properties within an interfaceursus
12/17/2018, 4:38 PMRuckus
12/17/2018, 4:38 PMShawn
12/17/2018, 4:39 PMval foo: Foo get() = ...
is a valid getter, val <T> foo: T get() = ...
is notursus
12/17/2018, 4:40 PMShawn
12/17/2018, 4:40 PMRuckus
12/17/2018, 4:42 PMursus
12/17/2018, 4:42 PM()
😄Ruckus
12/17/2018, 4:44 PM()
has semantic meaning. While I understand the urge to save characters, doing so at the cost of readability is a Bad Thing™.ursus
12/17/2018, 4:44 PMRuckus
12/17/2018, 4:45 PMursus
12/17/2018, 4:45 PMfooProvider.foo<SomeFoo> vs fooProvider.foo<SomeFoo>()
Pavlo Liapota
12/17/2018, 4:46 PMval <T> foo: T
in interface, how would you implement it in a class?
In your example:
override val appComponent: AppComponent
get() = ...
there is no <T>
here anymore.ursus
12/17/2018, 4:47 PMT
Ruckus
12/17/2018, 4:47 PMfoo
to be a value there, so how can I dictate what type the value is when the class already has it.ursus
12/17/2018, 4:47 PMPavlo Liapota
12/17/2018, 4:48 PMT
? just cast as T
?ursus
12/17/2018, 4:48 PMRuckus
12/17/2018, 4:48 PMfooProvider.foo<String>
?ursus
12/17/2018, 4:49 PMRuckus
12/17/2018, 4:50 PMursus
12/17/2018, 4:50 PMRuckus
12/17/2018, 4:50 PMursus
12/17/2018, 4:50 PMPavlo Liapota
12/17/2018, 4:51 PMfooProvider.foo<SomeFoo>
instead of
fooProvider.foo as SomeFoo
?ursus
12/17/2018, 4:52 PMRuckus
12/17/2018, 4:52 PMursus
12/17/2018, 4:52 PMRuckus
12/17/2018, 4:53 PMursus
12/17/2018, 4:53 PMRuckus
12/17/2018, 4:54 PMursus
12/17/2018, 4:54 PMRuckus
12/17/2018, 4:54 PMursus
12/17/2018, 4:54 PMRuckus
12/17/2018, 4:55 PMShawn
12/17/2018, 4:56 PMursus
12/17/2018, 4:56 PMRuckus
12/17/2018, 4:57 PMursus
12/17/2018, 4:57 PMPavlo Liapota
12/17/2018, 4:57 PMThe purpose of generics is to make your code type safe, not pretty.
ursus
12/17/2018, 4:59 PMRuckus
12/17/2018, 4:59 PMursus
12/17/2018, 5:01 PMRuckus
12/17/2018, 5:03 PMPavlo Liapota
12/17/2018, 5:04 PM()
?
Or use generics for type inference?Ruckus
12/17/2018, 5:04 PMursus
12/17/2018, 5:04 PMShawn
12/17/2018, 5:05 PMPavlo Liapota
12/17/2018, 5:05 PMfoo()
🙂Shawn
12/17/2018, 5:05 PMT
breaks that notion and takes it out of the realm of propertiesRuckus
12/17/2018, 5:07 PMgetFoo()
here. It makes it clear that the data is being fetched, and there are generics in play. Using getX()
in Kotlin only feels strange because Java, which didn't have a good way to separate the concepts of accessing data vs fetching data (if that makes sense).ursus
12/17/2018, 5:08 PMThey hold true where you expect properties to be data
what does "data" mean to you?Ruckus
12/17/2018, 5:08 PMursus
12/17/2018, 5:09 PMRuckus
12/17/2018, 5:11 PMShawn
12/17/2018, 5:12 PMfooProvider.<SomeView>foo
returned the exact same thing as fooProvider.<String>foo
ursus
12/17/2018, 5:12 PMRuckus
12/17/2018, 5:13 PMdoSomehtingAndReportSuccess(): Boolean
isn't a getter. From an implementation standpoint, sure, the computer doens't really see a difference. But code should be for humans to read and only incidentally for computers to execute.ursus
12/17/2018, 5:13 PMShawn
12/17/2018, 5:14 PMRuckus
12/17/2018, 5:15 PMursus
12/17/2018, 5:15 PMRuckus
12/17/2018, 5:15 PMursus
12/17/2018, 5:17 PMShawn
12/17/2018, 5:18 PMRuckus
12/17/2018, 5:19 PMursus
12/17/2018, 5:20 PMRuckus
12/17/2018, 5:21 PMursus
12/17/2018, 5:22 PMRuckus
12/17/2018, 5:23 PMval nameObservable = ObservableValue("name")
var name
get() = nameObservable.get()
set(value) = nameObservable.set(value)
From an implementation standpoint, name
is logic. From a user's standpoint, it's not.ursus
12/17/2018, 5:25 PMRuckus
12/17/2018, 5:25 PMursus
12/17/2018, 5:26 PMRuckus
12/17/2018, 5:26 PMursus
12/17/2018, 5:26 PMRuckus
12/17/2018, 5:26 PMursus
12/17/2018, 5:27 PMRuckus
12/17/2018, 5:28 PMShawn
12/17/2018, 5:28 PMursus
12/17/2018, 5:29 PMRuckus
12/17/2018, 5:29 PMursus
12/17/2018, 5:31 PMRuckus
12/17/2018, 5:31 PMShawn
12/17/2018, 5:33 PM40 72 75 63 6b 75 73 74 62 6f 6f 6d 20 79 65 73 2c 20 70 72 65 63 69 73 65 6c 79
ursus
12/17/2018, 5:33 PMShawn
12/17/2018, 5:34 PM{ -> }
is just an object of sorts under the hood, right? Are you lying to yourself?ursus
12/17/2018, 5:35 PMRuckus
12/17/2018, 5:35 PMShawn
12/17/2018, 5:35 PMRuckus
12/17/2018, 5:36 PMursus
12/17/2018, 5:36 PMRuckus
12/17/2018, 5:38 PMursus
12/17/2018, 5:39 PMShawn
12/17/2018, 5:39 PMursus
12/17/2018, 5:39 PMRuckus
12/17/2018, 5:39 PMursus
12/17/2018, 5:39 PMRuckus
12/17/2018, 5:40 PMursus
12/17/2018, 5:41 PMShawn
12/17/2018, 5:41 PMRuckus
12/17/2018, 5:42 PMursus
12/17/2018, 5:42 PMShawn
12/17/2018, 5:43 PMRuckus
12/17/2018, 5:43 PMursus
12/17/2018, 5:44 PMRuckus
12/17/2018, 5:44 PMursus
12/17/2018, 5:45 PMShawn
12/17/2018, 5:46 PMRuckus
12/17/2018, 5:46 PMyou cannot argue about anything, if no axiomatic baseline is establishedSure you can. You just need to establish a convention. There's no axiomatic truth in programming. With the advent of Quantum processing and other non-binary processors, "bit" is just a convention.
Shawn
12/17/2018, 5:47 PMursus
12/17/2018, 5:47 PMRuckus
12/17/2018, 5:47 PMShawn
12/17/2018, 5:47 PMval
with something that strongly resembles a function doesn’t mean there’s no point in treating them differently when writing said val
or consuming itRuckus
12/17/2018, 5:50 PMursus
12/17/2018, 5:50 PMRuckus
12/17/2018, 5:52 PMursus
12/17/2018, 5:52 PMShawn
12/17/2018, 5:53 PMursus
12/17/2018, 5:53 PMRuckus
12/17/2018, 5:56 PMclass Bounds(
var minX: Double,
var maxX: Double,
var minY: Double,
var maxY: Double
) {
var width: Double
get() = maxX - minX
set(value) {
maxX = minX + value
}
// Same idea for height
}
ursus
12/17/2018, 5:57 PMRuckus
12/17/2018, 5:57 PMursus
12/17/2018, 5:58 PMRuckus
12/17/2018, 5:59 PMursus
12/17/2018, 6:00 PMRuckus
12/17/2018, 6:01 PMShawn
12/17/2018, 6:02 PMRuckus
12/17/2018, 6:02 PMursus
12/17/2018, 6:03 PMShawn
12/17/2018, 6:03 PMRuckus
12/17/2018, 6:03 PMursus
12/17/2018, 6:04 PMRuckus
12/17/2018, 6:05 PMShawn
12/17/2018, 6:06 PMRuckus
12/17/2018, 6:06 PMursus
12/17/2018, 6:07 PMShawn
12/17/2018, 6:08 PMwidth
is a computed property of Bounds
there - the computation relies only upon properties within the class and doesn’t have any side effects. I think that makes that accessor safe to ship to a consumer labeled as a propertyRuckus
12/17/2018, 6:08 PMShawn
12/17/2018, 6:08 PMBounds
is supposed to representalex
12/17/2018, 6:08 PMRuckus
12/17/2018, 6:09 PMShawn
12/17/2018, 6:09 PMRuckus
12/17/2018, 6:09 PMShawn
12/17/2018, 6:11 PMalex
12/17/2018, 6:11 PMursus
12/17/2018, 6:12 PMRuckus
12/17/2018, 6:12 PMursus
12/17/2018, 6:13 PMRuckus
12/17/2018, 6:13 PMursus
12/17/2018, 6:13 PMwidth
because philosophically it is more of a property than a function, even thoughits computedShawn
12/17/2018, 6:14 PMursus
12/17/2018, 6:14 PMShawn
12/17/2018, 6:15 PMRuckus
12/17/2018, 6:15 PMyou almost had me at...I wasn't trying to get you or deceive you in any way.
ursus
12/17/2018, 6:15 PMRuckus
12/17/2018, 6:16 PMursus
12/17/2018, 6:16 PMRuckus
12/17/2018, 6:19 PMalex
12/17/2018, 6:20 PMursus
12/17/2018, 6:22 PMRuckus
12/17/2018, 6:22 PMursus
12/17/2018, 6:22 PMval foo: T
get() = whatever as T
the end 😄Ruckus
12/17/2018, 6:23 PMursus
12/17/2018, 6:24 PMShawn
12/17/2018, 6:24 PMursus
12/17/2018, 6:25 PMRuckus
12/17/2018, 6:25 PMursus
12/17/2018, 6:26 PMRuckus
12/17/2018, 6:26 PMthe problem is wrong if it yields uncertain answersIn math, sure. Not so much in programming.
ursus
12/17/2018, 6:26 PMRuckus
12/17/2018, 6:27 PMursus
12/17/2018, 6:28 PMRuckus
12/17/2018, 6:28 PMursus
12/17/2018, 6:29 PMRuckus
12/17/2018, 6:30 PMursus
12/17/2018, 6:31 PMRuckus
12/17/2018, 6:35 PMursus
12/17/2018, 6:38 PMaarjav
12/18/2018, 4:15 AMfooProvider.usingFoo { Int it -> it * 5 }
. Haven't tried it. Also I haven't worked with Android but I'm not completely sold on design of getById
returning T
arbitrarily. I think it should at least take in something like a Key<T> type but then again it's not really solving the problem.