Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Serialization of EFun objects for exported functions isn't implemented #47

eriksoe opened this Issue Jan 23, 2011 · 3 comments


None yet
1 participant

eriksoe commented Jan 23, 2011

==== Current behaviour:
1> erlang:term_to_binary(fun erlang:'not'/1).
** exception error: {not_implemented,"Encode for erjang.m.erlang.ErlBif$FN_not__1",

==== Desired behaviour:
Function objects for exported functions should be serialized using EOutputStream.write_external_fun(module, function, arity).


eriksoe commented Jan 23, 2011

At present, the EFun objects for exported functions do not contain their module and function name except as encoded in the class name.

Related, EFun subclasses for closures contain much code which could be moved to a common superclass for all similar closures:

  • fields index, old_index, pid, and fv1..fvN.
  • get_pid(), get_id(), get_env() and encode()

I suggest that common superclasses be introduced:

  • For exported functions of arity N: EFun{N}_Exported extends EFun{N}
    (with fields containing module name and function name, and a constructor populating both;
    and the method encode().).
  • For closures of arity N with M free variables: EFun{N}_Closure{M} extends EFun{N}
    (with fields index, old_index, pid, and fv1..fvM and an appropriate constructor;
    and methods get_pid(), get_id(), get_env() and encode().)

In addition to solving the present issue for exported functions, class sizes (and possibly module loading time?) would be reduced.


eriksoe commented Jan 23, 2011

Note that while
erlang:term_to_binary(fun erlang:'not'/1).
fails, an equivalent function object can be encoded:
erlang:term_to_binary(fun(X)->erlang:'not'(X) end).
with success.
(This is due to encode() being code generated for all local functions but for none of the exported ones.)


eriksoe commented Jan 25, 2011

Implemented (along with common superclasses for exported functions).

This issue was closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment