cos I want to build a `TextView` instance with som...

# announcements

[robinchew]

cos I want to build a TextView instance with something like:

render(TextView::class, hashOf("text", "abc123"))

[Shawn]

this is ancillary to the main discussion on constructors, but you could make this a bit more idiomatic using a reified type param here

[robinchew]

sure. so how would the render function look like so that the class from the first argument can be instantiated?

[Shawn]

fun <reified T : Any> render(params: Map<String, String>): T? {
  return T::class.primaryConstructor?.call(params)
}

// called as such
val view = render<TextView>(mapOf("text" to "abc123"))
// or with type inferencing
val view: TextView? = render(mapOf("text" to "abc123"))

[robinchew]

oh ok

[Shawn]

still, this seems rather brittle and may be better implemented not using reflection

[robinchew]

how is reflection involved?

[Shawn]

gaining references to arbitrary class constructors requires reflection

[Shawn]

KClass<T> is a member of kotlin.reflect

[robinchew]

Actually my example above isn't exactly what I'm doing, im doing this:

data class Virtual(val cls: KClass<out View>, val attr: Map<String, Any>)

fun realiseView(activity: Context, parent: ViewGroup, virtual: Virtual): View {
    val view = virtual.cls(activity)
    parent.addView(view)
    return view
}
realiseView(activity, vg, Virtual(TextView::class, hashOf("text" to "abc")));

I know you advised against KClass

[robinchew]

So do you advise against passing a class as argument?

[robinchew]

Or in the above case, keeping the class in Virtual

[Shawn]

I mean, there’s nothing wrong with passing KClass instances around, the problem is with disparate constructor signatures

[Shawn]

maybe all these View objects have the exact same constructor in which case I guess it’s nbd

[robinchew]

I do want to avoid using extensions

[Shawn]

I also don’t really know why you need a Virtual data class, but maybe you’re using it elsewhere

[Shawn]

what’s wrong with extensions?

[robinchew]

just seem like unnecessary code just to instantiate a class

[Shawn]

factory methods?

[Shawn]

I mean, idk what your use case is or anything about android views (I’m guessing), but this is pretty normal stuff afaik

[robinchew]

This didnt work:
virtual.cls.primaryConstructor?

[Shawn]

What didn’t work? that line on its own is a syntax error

[robinchew]

How would I access and call the primary constructor from virtual.cls then?

[robinchew]

I come from Python, so all these extra syntaxes is a learning process

[Shawn]

if you just need a reference to the primary constructor itself without invoking it, just virtual.cls.primaryConstructor, which will be of type KFunction<{class type}>?

[Shawn]

if you want to call it, I don’t think the reflection KFunction<T> type defines invoke, and instead provides .call(Any)

[robinchew]

.primaryConstructor don't exist

[robinchew]

there is .constructors though, but I gotta loop it

[robinchew]

If I don't use KClass, then TextView:class will complain

[Shawn]

well, sure, that’s like saying “I didn’t import java.lang.List and now my function that needs List is complaining”

[Shawn]

there’s nothing wrong with KClass itself, I’m just trying to warn against this kind of arbitrary factory method

[Shawn]

you can still do it lol

[Shawn]

I’m not a cop

[Shawn]

and to do it you’ll need reflection, so

[Shawn]

use KClass

[robinchew]

Alright, I'll try to get it working with KClass first, then I'll explore alternatives

[robinchew]

I still can't use .primaryConstructor though. Don't exist

[Shawn]

.primaryConstructor looks like an extension val, check to see if you have import kotlin.reflect.full.primaryConstructor at the top of the file

[Shawn]

should be available on Kotlin/JVM since 1.1

[robinchew]

unresolved reference full

[Shawn]

What version of Kotlin do you have included?

[Shawn]

Assuming you’re using gradle

[robinchew]

1.2.41

[Shawn]

wait, hm, I wonder if you’re missing some stuff since android JVM is a bit different than regular JVM

[robinchew]

should i explore another way, cos it just looks complicated importing all these things just to instantiate a class.

[Shawn]

I mean, can’t you just directly use your respective view constructors

[Shawn]

TextView(params)

[robinchew]

TextView is kept inside the Virtual data class

[robinchew]

so I need virtual.cls(params) or equivalent to work

[Shawn]

no I mean, wherever you were planning on using myFunc

[Shawn]

what is this Virtual data class anyhow

[robinchew]

just something I made up

[Shawn]

why do you even need it? I feel like this is a crazy x-y problem

[Shawn]

also check out #C0B8M7BUY

[Shawn]

and the other more specific android channels if you need them

[robinchew]

I think it isn't crazy to store a class as a value

[robinchew]

and then to instantiate it later

[Shawn]

no, not in a vacuum, I suppose

[Shawn]

If you need to defer instantiation of a class, why not use a lambda?

[Shawn]

val myBuilder = { MyClass(params) }

[robinchew]

That's an option

[Shawn]

can even use invoke

[Shawn]

val view = myBuilder()

[robinchew]

I guess the essence of the question is why this doesn't just work:

val boo = TextView
        boo(activity);

[Shawn]

val foo = TextView in Kotlin doesn’t get you a type-like reference to a given class

[robinchew]

Then I try to solve that with:

val boo = TextView::class;
        boo(activity);

Which complains about not having invoke method

[Shawn]

specifically it’ll yield a reference to TextView.Companion or result in a compile error if there is no companion object defined on TextView (which there probably isn’t)

[robinchew]

so complex

[robinchew]

I think I like your lambda idea

[Shawn]

like I said, TextView::class doesn’t let you use the reference like you would like if you were just calling a constructor by hand

[Shawn]

really what you might want is val foo = ::TextView

[Shawn]

Bar != KClass<Bar>

[robinchew]

this didn't work either:

val boo = ::TextView
        boo(activity)

[robinchew]

overload resolution ambiguity

[Shawn]

right, and therein lies the problem

[Shawn]

you can’t really have a function that arbitrarily constructs any class you tell it to

[Shawn]

there can be any number of constructors defined for a given class, and you’ll have to manually resolve which constructor you need based on your parameters

[Shawn]

However

[robinchew]

i dont understand why it's ambiguous, TextView accepts 1 argument with Activity type, and I've provided it

[Shawn]

There isn’t a single other constructor for TextView?

[robinchew]

there are, but I've only provided 1 argument, so it should clearly pick the constructor with 1 argument of Activity type

[robinchew]

This works TextView(activity)

[robinchew]

and it knows which constructor to run for that

[Shawn]

well sure

[Shawn]

but when you’re getting the reference

[Shawn]

val foo = ::TextView

[Shawn]

which constructor should it pick

[robinchew]

I guess the smarts are lost at that point

[robinchew]

I thought it will pick the right constructor when you execute foo

[Shawn]

it can’t

[robinchew]

ok then I understand

[robinchew]

So how do I explicitly pick the constructor

[Shawn]

Foo(params) will resolve which constructor you need at compile-time

[Shawn]

in any case, you can specify which constructor you want using a type annotation

[Shawn]

val ctor: (Context) -> TextView = ::TextView

[robinchew]

Fark I got bitten by this before!

[robinchew]

I mean your solution works, and I've applied it before. And I keep forgetting it.

[Shawn]

happens ¯\_(ツ)_/¯

[robinchew]

Actually this is a bit different

[Shawn]

this is what I meant by this being an x-y problem

[robinchew]

I thought () -> is reserved for functions

[robinchew]

didn't know you can use it for classes

[robinchew]

ok I didn't know that's what you meant by x-y

[Shawn]

i mean. a constructor for a class T is a function that returns T, no?

[robinchew]

Ok I didn't know that ::TextView is the constructor and not the class.

[Shawn]

yup

[robinchew]

Anyway thanks, I can sleep now at 6am!

[robinchew]

it's hard to google for these problems as well. Pain in the ass.

[Shawn]

it helps to try to understand what the problem is at an abstract level

[Shawn]

rather than going directly to “how do I get a constructor from a KClass”

[Shawn]

but it’s definitely a skill you pick up over time, as you gain the intuition for a given language

[robinchew]

I'm good for now, thanks again. I'm out.