Repository navigation
Classes #3052
Description
Question
Is there a guide or explanation for how classes written in as files are compiled by assemblyscript and usable from there ? Are constructors, static methods, ordinary methods ok and under which conditions ?
The as-bigint package and repo uses them, and apparently it compiles under their obsolete version of assemblyscript and not under current version – and I could not get an explanation for how that's possible.
The as-mpz seems to do the same, and while it uses a more recent version of assemblyscript to do so, the code (especially the built code) is very intricate to understand for a newcomer. In particular, it is very long within a single file and so what makes it work or doesn't work is not easy to understand.
Which is also the reason for guides and documentation to exist: because if retro-engineering is not an efficient way to learn a language.
Activity
JairusSW commentedon Oct 21, 2026
@Gouvernathor are you attempting to expose (via
export class ...) to the host?Generally, classes behave the exact same way that they would in classic TypeScript. You can also export them and consume as an import (eg.
export class Foo {}andimport { Foo } from "./foo"), just can't export them from the entry file to be exposed to hostperhaps i'll go and write some tutorials some time
Gouvernathor commentedon Oct 22, 2026
So, you're talking about the entry file : does that mean that an AS library can't export/provide a class to other AS code ? Or is it just unable to be exported to JS ?
I'm not attempting anything right now, I'm trying to understand what's possible to be done.
JairusSW commentedon Oct 22, 2026
Unable to export to js (or whatever host you're using eg wasmtime, wazero, etc)
Everything else works as expected
dcodeIO commentedon Oct 22, 2026
Perhaps for context: In early versions of AS, there used to be some rudimentary bindings for classes exported to JS, say, an instance method was exported under the name
MyClass#someMethodwith parameters (this: i32, ...). That was later dropped however, partly in anticipation of Wasm GC <-> JS interop, and partly because it interfered with dead code elimination because class exports aren't fine-grained and kept all the static and instance members of the class alive via the exports created for each of them, leading to unexpected binary sizes for some users.Currently, to get something similar, one would export wrappers instead, for example:
Or, better, a wrapper that does more than just that.
Gouvernathor commentedon Oct 23, 2026
Aside classes, is it possible to export objects (as in, POJOs) ?
I think it would be useful if the legacy class-export you mentioned was still available but as an opt-in, for instance a decorator on an exported class, which could be documented as unstable and subject to removal if and when a GC interop feature you mentioned comes to life. For people who read the doc, found the decorator, understood the drawbacks you mentioned and still find it worthwhile for their use.
It's a bit sad to see something that worked in earlier versions disappear, and which you can't very easily emulate (as it concerns the JS-glue-code generation).