Jochen, thanks a lot!
> On 29 Aug 2021, at 19:22, Jochen Theodorou <blackd...@gmx.org> wrote: > On 28.08.21 14:46, OCsite wrote: >> Pity not even today's Java supports something like Objective-C runtime >> support for managing the methods in a class :( >> >> Anyway, I might try to create my (sub)classes dynamically at runtime — >> this is an idea which did not occur to me before; and although I can see >> some hurdles (for one, the classes which I need most to support dynamic >> methods/properties are database classes; and the source from which I >> read in the information of dynamic methods is... the very database; I'll >> have to find some trick here), it looks pretty promising. > > Java does offer you in a very limited way to add a method Does it? I might be misunderstanding something, but below, I read methods cannot be added: > at runtime by using an agent and instrumentation. However: > """ > Instances of the redefined class are not affected. > > The redefinition may change method bodies, the constant pool and > attributes (unless explicitly prohibited). The redefinition must not > add, remove or rename fields or methods, > ... > Of course you can also redefine the class on loading, then you can > basically do whatever. Yup, I guess conceptually, there is not much difference between (a) creating a subclass containing methods I need programmatically at runtime, or (b) creating a bare subclass compile-time and then add the methods when it gets loaded. Of course, it might well prove one or the other is technically much easier. Which of these two approaches would you recommend to start with? I am addressing Groovy 3 only; no need to support older releases. If it helped, I guess I even might skip directly to Groovy 4; but frankly, I've got enough of my own problems, and I'd rather stick with a stable Groovy release :) > But for Groovy in general I found this always much too limiting. I would happily stick with the metaclass stuff, but for the problems with reflexion (which is used pretty heavily by my libraries, namely, WebObjects). Meantime I've considered another trick, essentially (the details slightly differ, not worth pursuing here) I found (probably) a way to reliably trap all the exceptions caused by those non-existing accessor methods and use proper getters/setters in the appropriate handlers. I am afraid this approach would prove too slow, but perhaps it is worth trying, too... Thanks a lot and all the best, OC
