Hello Jason,
do you have the time to explain this problem more in detail?
My Go interpreter gomacro (I think you already met it),
solves the problem of invoking `b.After(a)` as follows at "compile time",
i.e. during typecheck and translation:
1. detects that `b` is a `time.Time`.
2. looks up the method "After" in the type `time.Time` (and `*time.Time`,
in case the method expects a pointer receiver)
3. the returned reflect.Value is a `func (time.Time, time.Time) bool`
because when you lookup methods from `reflect.Type`
the receiver is **not** bound already
4. it prepares an assignment `c := b.After` to be executed at runtime -
this instead will return a closure `func (time.Time) bool` because the
receiver is already bound to `b`
5. it prepares a call `c(a)` to be executed at rutime - this will call
`b.After(a)`
alternatively, 4. and 5. could become:
4alt. it prepares a call `time.After(b, a)` to be executed at rutime by
using the reflect.Value returned by looking up the method "After" in the
type `time.Time`
In both cases, gomacro detects with a method lookup from `time.Time` that
"After" is a method and behaves accordingly at "compile time",
without waiting for the reflect.Value of `b.After`, which is only available
at runtime.
It's not clear to me why you had to resort to distinguish methods vs.
functions *after* you obtained the reflect.Value `b.After` instead of
distinguishing them *before*
i.e. during typecheck or a similar phase - can you explain?
Regards,
cosmos72
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
