Okay, valid - but how come this concern applies to arguments names and not
to field and function names?

Dart addresses this problem by making reflection entirely opt-in, maybe
that's something to consider - a file-level directive of some sort to
enable reflection. Usually developers know whether or not they need/want
something to be reflected, since it's usually a means of integrating with
some service or helper that consumes the metadata.

This would address your concerns about binary footprint even better, right?
You could optimize away all redundant metadata. And perhaps additionally
this could make it harder to reverse code, which is probably less of a
concern for e.g. models or "plugins" that deliberately expose metadata for
other components to consume via reflection.

Of course making reflection opt-in would be a BC break, but a fairly small
one, forcing developers to take a position and decide whether each file
should be reflected or not.

On Wed, Oct 8, 2014 at 1:47 PM, Jan Mercl wrote:
On Wed, Oct 8, 2014 at 1:34 PM, Rasmus Schultz wrote:
If what you're saying is the compiler doesn't need this information for
itself, that may be true - but it would be nice, for the sake of
completeness and consistency in the reflection API, if the names of
arguments could be reflected, same as the names of most other members.
I don't think it would be nice. It would, perhaps substantially,
inflate the size of every executable when only rarely needed.

However, If really desired, regardless of me thinking such need is
questionable, embed the source part as a string constant ("//go:
generate") and in init() parse it and produce some mapping from
fnName, argName -> argIndex.

You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 5 of 8 | next ›
Discussion Overview
groupgolang-nuts @
postedOct 8, '14 at 2:49a
activeOct 8, '14 at 12:22p



site design / logo © 2022 Grokbase