You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Doing it this way carries several disadvantages with it:
More boilerplate. There is loads of code that shouldn't need to be there in the above code example.
Less errors are detected at compile-time. When we create an empty map, we know the type of that term is map a map. Even though we know that, there is nothing stopping us today from calling something like a list function on such a term today.
Potentially more runtime checks.
How this could be remedied
I have two solution for how this could be solved:
Introduce a separate and more specific NifTerm type for each term. This is somewhat the same as what we have for atoms today. (although that is done for different reasons)
Have another type parameter on NifTerm, NifTerm<Variant>. This Variant type parameter would normally be Any. This could have all the method implementations we have today. When calling a method with a guaranteed return type (like map_put, which will always return a map term), we can return a term parametrized with a Map type. NifTerm<Map> could then have specific implementations which can not fail with type errors.
Any and all feedback is welcome. Is this a good idea? Any improvements? @scrogson@jorendorff
The text was updated successfully, but these errors were encountered:
This is mostly a suggestion. I am unsure if this is a good idea, and am looking for input on the matter.
The situation today
With NifTerm today, doing stuff like constructing a map is a little awkward. You end up having to do stuff like:
Doing it this way carries several disadvantages with it:
How this could be remedied
I have two solution for how this could be solved:
NifTerm<Variant>
. ThisVariant
type parameter would normally beAny
. This could have all the method implementations we have today. When calling a method with a guaranteed return type (likemap_put
, which will always return a map term), we can return a term parametrized with aMap
type.NifTerm<Map>
could then have specific implementations which can not fail with type errors.Any and all feedback is welcome. Is this a good idea? Any improvements? @scrogson @jorendorff
The text was updated successfully, but these errors were encountered: