@impl GenServer
attribute is included for all autogenerated callback functions.
- removed Elixir 1.4 warnings
- Bugfix:
export: __MODULE__
didn't work in operations macros
- fix compund matches with structs
- Bugfix: support compound matches
- Bugfix: support ExActor macros from other macros
- Support interface & handler specific guards (see docs for details)
- Remove warnings on Elixir 1.1
- Bugfix: pattern matching on
nil
state didn't work properly
- Relaxed Elixir version dependency to
~> 1.0
- Bugfix: Proper lineno generation in client code.
- Improve pattern matching handling (see docs for details)
- Added parameterizable timeout in calls (see docs for defcall)
- Fixed the docs link in
mix.exs
defstart
macro which simplifies definition of starters.defmulticall
anddefabcast
macros for distributed support.defhandlecall
,defhandlecast
, anddefhandleinfo
for implementation of handlers only- default arguments can be specified via
\\
defcall
anddefcast
can be called without specifying the body- Support for
timeout
andhibernate
replies.
- Pattern matching now works on interface functions as well (previously it was done only in handler functions).
- Starter functions are not automatically generated anymore. You can use
defstart
macro to create them. - When calling
use ExActor.*
options:initial_state
, and:starters
are not available anymore. definfo
is renamed todefhandleinfo
- Option
export: false
is not available indefcall
anddefcast
. If you want to implement just handlers, usedefhandle*
For migration examples, check here and here
A non exhaustive list of changes you may have to do in your project:
- Add explicit starters via
defstart
. If you need to supportstart
andstart_link
, you can do it like this:
defstart start(x, y)
defstart start_link(x, y) do
# initialization runs for both start/2 and start_link/2
end
- Replace all
definit
withdefstart
if possible, or use body-lessdefstart
with an explicitdefinit
. - If you used
initial_state
, set the state explicitly indefstart
. - Replace
definfo
withdefhandleinfo
.
- migrated to Elixir 1.0.0
- migrated to Elixir 1.0.0-rc1
- introduced
defcastp
anddefcallp
(see docs for more details)
- migrated to Elixir v0.15.0
- migrated to Elixir v0.14.0
- various internal refactorings (API and behavior remain unchanged)
- migrated to Elixir v0.13.3 (backwards incompatible with earlier versions)
- add
name
option to allow dynamic specification of registered alias while starting - make autogenerated start functions overridable
- add
starters: false
option to allow omitting generated start functions - add support for
export: {:via, module, name}
- migrate to new
GenServer
- adapted to Elixir v0.13.1 (backwards compatible with 0.13.0)
- "dummy" empty version due to Hex limitations
- removed implicit "smart" returns
- removed default
use ExActor
- migrated to Elixir v0.13.0
This version introduces some significant changes. If you don't want to incorporate them, there is a tag for 0.1. Keep in mind that I won't maintain the 0.1, so your best option is to fork it and maintain it yourself.
On the plus side, the migration to the new version should not be very complicated (unless you're relying on tuple modules support). Here are quick pointers for migrating from old API to the new one:
The point of predefines is to make the decision about default implementations explicit. Earlier, you used use ExActor
and the default implementation was implicit. Now you have to decide which implementation do you want, or you can easily make your own. If you want to keep the status quo, just use use ExActor.GenServer
.
definit do: some_state # deprecated
definit do: initial_state(some_state)
defcall op, do: response # deprecated
defcall op, do: reply(response)
defcast op, do: :ok # deprecated
defcast op, do: noreply
definfo msg, do: :ok # deprecated
definfo msg, do: noreply
Beside these "special" responses, you can use standard gen_server
responses. The reason for this change was again to make things more explicit, and aligned with standard gen_server
approach.
There's no way around this - if you use ExActor tuple modules support, you need to change the code to classical functional approach, or remain on version 0.1. The tuple modules support was more a hack, to make some code in blog articles more OO-ish. In hindsight, this was a mistake that made the ExActor code more complicated, so I decided to drop it.