dOrgJelli
dOrgJelli
I agree, adding `polywrap wrap build --no-codegen` sounds like a nice feature :D
Left a comment here: https://github.com/polywrap/technical-council/issues/69#issuecomment-1211143701 I think the best way to do this is to allow wrappers to use their current URI within their code. For example, `this.uri` inside of...
Okay after doing more thinking about this here's what I'm thinking: - Wrappers can indeed have multiple URIs (ex: `domain.eth` -> `ipfs/QmHASH`) - We want to support 2 ways of...
NOTE: the above solution does not account for "parallel paths" where you may have multiple URI resolution paths that point to the same resulting URI. Example: ``` ens/a.eth -> ipfs/QmHash...
@fetsorn @ramilexe can you please explain the OmniBlocks use-case that requires this feature? It will make it easier to know how to best support it.
Apologies for taking so long to review this @pileks, this was really well executed given how many potentially moving parts there are + legacy code. A few things I think...
@fetsorn why not do `Option | null`? Also I believe that in AssemblyScript if a property is `| null` you still have to list that property, and cannot omit it...
Okay I can definitely see the point here, I’m in favor of using ‘Box | null’ instead of Option
Ah good catch, didn't realize @Niraj-Kamdar had already created this. Will close the other one.
There is currently a WASI proposal for this functionality here: https://github.com/WebAssembly/wasi-random Before it is released, we could expose via a plugin.