vans163
Typespecing a map of arbitrary integer keys?
I am wondering if this is correct, this should be a map of arbitrary size (could be 0, could be 1000) of integer keys.
@type quests() :: %{Integer => any()}
defmodule GameState do
@type obj() :: %{0=> Integer, optional(1)=> Integer, optional(2)=> Integer}
@type quest() :: %{id: Integer, step: Integer, obj: obj()}
@type quests() :: %{Integer => quest()}
@type gamestate() :: %{quests: quests()}
@spec get_quests(gamestate()) :: quests()
def get_quests(gs) do
:erlang.map_get(:quests, gs)
end
@spec act(gamestate()) :: any()
def act(gamestate) do
quests = get_quests(gamestate)
cur_quest_id = quests
|> Map.keys()
|> List.last()
cur_quest = Map.fetch!(quests, cur_quest_id)
cur_objs = Table.QuestStep.by_id_order(cur_quest.id, cur_quest.step)
done_objs = Enum.filter(cur_objs, fn{idx,obj}->
cur_quest.obj[idx].amount >= obj.amount
end)
end
def go do
quest = %{id: 10010, step: 2, obj: %{0=> 14}}
quests = %{10010=> quest}
gamestate = %{quests: quests}
act(gamestate)
end
end
The idea here is to trigger a error from dialyzer here cur_quest.obj[idx].amount that .amount is not a valid key for obj().
Instead I get this, but if I call this from the REPL it works just fine. The function call succeeds.
lib/game/gamestate.ex:28:call
The function call will not succeed.
Table.QuestStep.by_id_order(Integer, Integer)
will never return since it differs in arguments with
positions 1st and 2nd from the success typing arguments:
(pos_integer(), 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9)
Can anyone advise please?
Most Liked
hauleth
Integer mean that you are matching against :"Elixir.Integer" atom, you wanted to use integer() type.
ityonemo
you probably want:
@type quests :: %{optional(integer) => any}
or maybe
@type quests :: %{optional(non_neg_integer) => any}
I prefer omitting parens on non parametric types, to cut down on line noise, but if you prefer keeping them in (which I believe is idiomatic?):
@type quests() :: %{optional(non_neg_integer()) => any()}
asummers
Last Post!
vans163
Heh dialzyer with typespecs is not what we were looking for. So not sure if I will continue looking into this.
Basically because of that lol.
Waiting now to see if Facebook reveals anything interesting on Nov, if they made a totally new static typed language that compiles to beam that seems useless. If they build a new analysis tool or IL to spot type errors in beam files/core erlang that is more interesting now.
If nothing interesting from FB will probably take an attempt at walking compiled beam bytecode.
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex










