Native method binding

[Maurizio Cimadamore]

On 18/12/2024 15:59, David Lloyd wrote:
> They're bad because they're a mis-fit. You end up creating a static 
> field holding a global singleton object of a class which is the single 
> possible implementation of the interface. That's what static methods 
> are _for_. If I designed a whole program that way, I'd be called 
> crazy. :-)

Ok.

Other languages (Scala) have other constructs to declare "bags of 
statics" e.g. an `object` declaration. That would probably alleviate 
some concerns.

But, one last comment I'd like to add on this topic is that what looks 
like an interface with only one impl, is often not exactly like that. At 
some point users will want to create multiple instantiation of that 
interface, with different e.g. SymbolLookup objects, or other custom 
properties (e.g. Linker options). At which point having an interface, 
and cleanly separating the interface definition from _how_ that is 
implemented/linked might prove beneficial.

With jextract, we're already at the point where users feel the need to 
customize the way in which symbols are searched in libraries in more 
finer-grained way. Which is why, very likely, we will transition from 
bags of static methods into something more structured -- that can be 
used as a bag of static methods in the common case, but can also be 
instantiated and customized if needed.

Maurizio