I'll probably have something else to add tomorrow (although, honestly, I'm cool with however you want to do this—just weighing in on how things look from where I sit). But maybe you can clarify this one thing for me:
> On Aug 31, 2016, at 6:14 PM, John Rose <john.r.r...@oracle.com> wrote: > >> It's a given that you have statics (see your Int128 declaration, for >> example). If instance methods are practically free after that, fine. But if >> not, there's no particular reason to support them. We don't have >> polymorphism (for Q types, anyway -- I'm assuming no automatic boxes, per >> (1)), and it's just as easy -- easier, in fact -- for a client to do >> "invokestatic Val.m(QVal;)I" as it is to do "invokedynamic [vinvoke ...]". > > That's true, if we can settle on a stable enough translation strategy > that we can map virtual-appearing APIs to static methods. The indy > trick would let us put off some of that. Why put it off? Well, static > methods are already standard API points, and binding them from > fluent (x.f()) calls as well will come as a surprise, because of the alias. ... > Removing fluent calls is not a deal-breaker, but it will feel like > a cut, and too many such cuts will make the prototype programming > model too difficult even for super-users. I don't understand what "virtual-appearing APIs" and "fluent calls" mean in this context. Maybe I have the wrong idea of what we're talking about? My presumptions: we're defining a bytecode format. There is zero Java language support. In that context, the syntax of bytecode method invocations is never "fluent"—you always have to spell out everything. The difference between 'invokestatic' and 'vinvoke' is minimal, and there is no ergonomic benefit to one or the other; meanwhile, both of these have plenty of ergonomic benefits over 'invokedynamic', if we really care about that, because all you need is a Methodref, not a complicated bootstrap method table. But I really don't think ergonomics of the bytecode format are a significant concern right now? I get the feeling you've skipped ahead to some sort of language support, but it's unclear what you intend it to look like. —Dan
