Nevermind for the first idea.. this is even more complex than I thought.
First it requires generalized interfaces. I don't see it being a major 
problem in the long run.

But I thought I could work around not having value scoped type declarations 
but turns out it is not the case after all.
Realized that it requires dependent types. (to create new types from some 
value, in my case here, the specific document should have its specific 
Element constructor types)

Don't see that happening any time soon, emphasis on soon, unfortunately.

So I guess, I'd like to be able to hack around this by maintaining my own 
function-value dependencies by hand but that still requires to be able to 
have a stable id for function values.
Essentially, doing dependent types manually.

Should be much easier I think. Just requires a stable id/ reference for 
function values if I'm not mistaken?



On Sunday, June 18, 2023 at 1:38:33 PM UTC+2 atd...@gmail.com wrote:

> I have exposed the following problem in a bit more details here:
>
> https://gist.github.com/atdiar/6568964896231bfde734f6bddf9ff46c
>
> Basically, I need to modify the implementation of the method of a given 
> type depending on the encasing scope of the value its called on. (and not 
> just the value itself)
>
> the reason being that the value is a func type, not a struct type which I 
> could modify to add a reference to external scope/state.
>
>
> I could easily modify the implementation of the type if we had 
> generealized interfaces/ union types. That would solve it at compile time.
>
> But I would be happy just being able to assign a stable id to a func value 
> at runtime, as a non-pointer reference. (probably via a runtime pkg 
> function).
> I can do the latter now using fmt.Sprint on a function but there is no 
> guarantee of stability. It's simply that the GC is not a moving compactor 
> for instance which may allow it for now.
>
> Any idea?
>
> Can I fill an issue for the stableid idea or that's not somethign that's 
> actually possible?
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d0a0b0fe-0356-44b7-bd30-529923af9cebn%40googlegroups.com.

Reply via email to