Changed KwdFile loading algorithm

[ArchDemons]

What changed:

1. KwdFile separate from it loading (to KwdFileLoader)
2. KwdFileLoader can partly load KwdFile (return Proxy) or fully (return KwdFile)

[tonihele]

As a general comment, we are doing something architecturally weird if we have to proxy and reflect our own code. I'm not a huge fan of how this might impact performance. The KWD data is kinda central to our operations. Yes, it should have an interface like you did.

Could we maybe just separate KWD to two different interfaces. Something like IKwdInfo and IKwd (IKwd extends IKwdInfo). Latter being the full blown one. Calling load would return this as IKwd. We would just manage this kinda from the source as we do now. So this minor hickup would be buried at the source and whomever uses it wouldn't have to know anything. Much like you did, but without proxies and reflection.

Or any other ideas?

[ArchDemons]

We haven`t performance problems in our case using Proxy classes. Also we can unproxy to get original object (small code modification) .

Could we maybe just separate KWD to two different interfaces. Something like IKwdInfo and IKwd (IKwd extends IKwdInfo).

We can take this way . But we can`t load IKwdInfo to IKwd on demand. I suggested this in #496 (comment)

Or any other ideas?

We can create proxy manually, without using java Proxy classes. Put inside loader, because outside its looks like interface. And wrote in each getter something like if (!loaded) { load(); } return this.field;

What way?

[tonihele]

We can create proxy manually, without using java Proxy classes. Put inside loader, because outside its looks like interface. And wrote in each getter something like if (!loaded) { load(); } return this.field;

Yes, I know, all IDEs can just generate a class that delegates all calls to the original object. Is this a proxy or a facade. But I still consider all this kind of a hack on something we can actually influence.

Here, yes, the design is a bit bad. But it is not extremely problematic. So the amount of energy we put into it, and the amount of mess or slowness any solution would give us, should be minimum.

To further expand what I suggested.. I mean:

public class KwdFile extends IKwd, IKwdInfo
public interface IKwd
public interface IKwdInfo -> load function would return IKwd

One could acquire, like you did, Kwds from some loader that can fix paths and whatever it does. But it would expose:

IKwd getKwd
IKwdInfo getKwdInfo

Handler would then know whether to load all of the file or not. And any usages would also have this power to fully read their Kwd file by expanding IKwdInfo to IKwd (via the load interface method).

This way, the downstream usages would be clear. That is what this is all about, right? Maybe the design is a bit quirky, I don't know. But there would be very little shenanigans involved. The interface would mask the internals on whether the file is fully loaded or not.

And this is also just a suggestion, not a mandate of any sorts.