On 12/17/2012 4:47 PM, deadalnix wrote:
On Tuesday, 18 December 2012 at 00:42:13 UTC, Walter Bright wrote:
On 12/17/2012 3:03 PM, deadalnix wrote:
I know that. I not arguing against that. I'm arguing against the fact that this
is a blocker. This is blocker in very few use cases in fact. I just look at the
whole picture here. People needing that are the exception, not the rule.
I'm not sure what you mean. A blocker for what?
And what prevent us from using a bytecode that loose information ?
I'd turn that around and ask why have a bytecode?
Because it is CTFEable efficiently, without requiring either to recompile the
source code or even distribute the source code.
I've addressed that issue several times now. I know I'm arguing against scores
of billions of dollars invested in JVM bytecode, but the emperor isn't wearing
clothes.
As long as it is CTFEable, most people will be happy.
CTFE needs the type information and AST trees and symbol table. Everything
needed for decompilation.
You do not need more information that what is in a di file.
Yeah, which is source code. I think you just conceded :-)
Java and C# put more
info in that because of runtime reflection (and still, they are tools to strip
most of it, no type info, granted, but everything else), something we don't
need.
There's nothing to be stripped from .class files without rendering them
unusable.
