Am 17.09.2015 19:57, schrieb John Rose:
On Aug 29, 2015, at 4:42 AM, Jochen Theodorou
[...]
This leads to a natural pattern: If the user wants to generate
dynamically selected calls to two or more overloadings of S.,
wrap all of the S. in corresponding C. overloadings. Add
extra arguments to
On Sep 17, 2015, at 10:10 AM, Michael Haupt wrote:
>
> ummm ... this seems to imply I can remove the findSuperConstructor() proposal
> from the Indy JEP. Incidentally, it's on my list for this week - and less
> work is always good. ;-) Even if, in this case, it leads to disappointment. I
> agr
s supposed to.
Since the wrapper constructors are marked private, it is impossible for
untrusted parties to inject malicious MH code. The MH could be replaced by a
private instance method, if there is no need to have a different MH at
different construction sites.)
What do you think? Is th
this will introduce several
trapdoors and additional complication.
Please let me know ...
Best,
Michael
> Am 29.08.2015 um 03:40 schrieb John Rose :
>
> The invokespecial-super-init dance is the thing MH's can't quite do, the
> "super" call every constructor (
ivalent
is not required... but I am not sure something like GenericInstance can
be done. In pure Java probably not
bye jochen
Am 29.08.2015 03:40, schrieb John Rose:
The invokespecial-super-init dance is the thing MH's can't quite do, the "super" call
every constructor (excep
The invokespecial-super-init dance is the thing MH's can't quite do, the
"super" call every constructor (except Object.).
It very hard to secure this pattern; just ask anybody who has worked on
(de-)serialization security.
But, we can look at it from a more limited point
