Kotlin seems to complain whenever I want to pass `this` to a parent constructor, what should I do? E...

# getting-started

[martmists]

Kotlin seems to complain whenever I want to pass this to a parent constructor, what should I do? Example:

class LzCompressedReader(private val input: InputStream) : InputStream, MyDataReader(this) {
    // Acts as MyDataReader, but pre-processes the InputStream to decompress
}

[Joffrey]

The solution is to not do this (no pun intended :D). Usually this opens the door to a bunch of unexpected behaviors, because this is not fully initialized at that point. Could you please elaborate on why you want to pass this to the parent constructor?

[martmists]

Because I want (nearly) identical behavior to MyDataReader, but with a few changes to e.g. how data is read. I can't use a different inputstream type, because Ghidra calls the constructor and it's out of my control.

[Joffrey]

In your example, why is LzCompressReader an InputStream AND a MyDataReader? This class hierarchy looks strange.

Also, why does MyDataReader need this and not just input? Maybe you could use inheritance and override the methods of MyDataReader from your reader if you just want to slightly change the behaviour. Or maybe you could use composition + delegation (especially if MyDataReader implements an interface).

[Joffrey]

When looking at it a bit more, it seems to me that you instead need:

class LzCompressedInputStream(source: InputStream) : InputStream {
    // wrap your things there
}

// and then:
val reader = MyDataReader(LzCompressedInputStream(source))

[martmists]

Unfortunately the majority of the logic for MyDataReader is in a single function, so I'd need to effectively copy-paste the code for it which I'm trying to avoid

[martmists]

In that case, how would I make it so the LzCompressedInputStream has access to the reader? Because it needs some data from there for processing (as Lz isn't exactly what's happening, but a more easily understood format)

[martmists]

Alternatively I could duplicate the logic but again, that's not desired

[Joffrey]

It's hard for me to help further without reading the whole actual code, but in essence I believe the problem stems from the fact that MyDataReader is not properly designed for inheritance and you're trying to use inheritance with it. And/or, LzCompressedReader mixes low-level responsiblities from an input stream with higher-level responsibilities from a reader.

Maybe the solution would be to extract some functionality from the "single function" of MyDataReader into multiple re-usable protected functions that inheritors could reuse to compose them differently. Or use composition instead, but that might also require changes in the design of MyDataReader.