I think you'll be able to achieve this cleanly with Kernel.get_in and
Kernel.update_in with Elixir 1.3. I'm sure there's more info somewhere, but
this is the extent of my knowledge at this time:
https://twitter.com/elixirlang/status/735942800039088129
-Greg
> On May 27, 2016, at 6:56 AM,
My contribution to the bikeshed ;-)
"regarding" and/or its abbreviation "re"
-Greg Vaughn
> On Jun 1, 2016, at 2:52 PM, Onorio Catenacci <catena...@gmail.com> wrote:
>
> Or even scenario:
>
> scenario "parsing invalid data" do
>
it into the middle of pipelines to examine things in the middle
of processing.
-Greg Vaughn
> On Oct 20, 2016, at 3:51 PM, jbo...@wistia.com wrote:
>
> In Ruby I've found Object#tap to be really useful when building out
> pipelines. I've wanted to grab for it several times in my Eli
of the language. Still, it's your choice to make.
-Greg Vaughn
> On Apr 27, 2017, at 7:25 PM, Thiago Majesk <thiagomgoul...@gmail.com> wrote:
>
> Hello everyone,
> First of all, I'd like to apologize if this is not the right place for this
> kind of question, please be patient :)
Is it so bad to write a simple helper function?
def update_if_exists(map, key, fun) do
case Map.has_key?(map, key) do
false -> map
true -> Map.update(map, key, nil, fun)
end
end
-Greg Vaughn
> On Oct 3, 2017, at 1:40 PM, Ary Borenszweig <aster...@gmail.com> wr
I like the original idea and would like to suggest another approach. What if
there were an additional Inspect.Opts of :transform? It then would enable this
sort of thing:
["thing1", "thing2"]
|> generate_more_things()
|> IO.inspect(transform: /1)
|> do_somethin
José, you are so gracious in dealing with the Elixir community. I appreciate
that very much. It has inspired me to work to be more gracious in my own life.
-Greg Vaughn
> On Apr 16, 2019, at 7:18 PM, José Valim
> wrote:
>
> Hi Tom,
>
> You probably meant it as a joke but
Can we have some fun with this? Maybe use the unicode "identical to" symbol? ≡
:-) (only half-joking)
-Greg Vaughn
> On Jul 2, 2019, at 4:02 PM, Bruce Tate wrote:
>
> I could learn to like /1, and also think that /1 fits Elixir's style
> of abbreviation. My vote is f
I still like `tally` (both a noun and verb) but I'm probably the only one.
`frequencies` is the only other name I like. No one has mentioned `histogram`
which I also like.
-Greg Vaughn
> On Oct 20, 2019, at 12:52 AM, José Valim
> wrote:
>
> Thanks Eksperimental and Derek!
>
with it.
Create and use your helper macro in your codebase if you want, but I don't want
to see this extra complexity in the core language/libraries.
--
Greg Vaughn
> On Oct 17, 2019, at 2:04 PM, Joel Wietelmann wrote:
>
> There's also `Kernel.match?/2`, which is awkward to use in an `if`
standard
library, I would always think of Harry Belafonte's _Day-O_ song and smile when
I use it ("come mister tally man, tally me banana")
(https://www.youtube.com/watch?v=6Tou8-Cz8is)
-Greg Vaughn
> On Oct 4, 2019, at 7:55 PM, José Valim
> wrote:
>
> So I am not a nativ
{a: []}, [:a, Access.at(0)])
nil
If this is a welcome direction, I'll be happy to submit my PR and work through
details of optimization, cleanup, exception wording, etc.
-Greg Vaughn
> On Feb 8, 2020, at 1:47 AM, José Valim wrote:
>
> For now, I don't think we should add a
and
move on.
-Greg Vaughn
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussi
ft through.
>
> %{"items" => nil} |> get_in(["items", Access.at(0, nilsafe: true)
>
> On Tuesday, January 28, 2020 at 8:10:04 PM UTC-6, Greg Vaughn wrote:
> Thanks, José. I agree with the need to be consistent. I will look at the
> bigger picture
ementation is. There is support in this thread for mil-safety (or
nil-ignorance as once presented) by default. I'm left wondering how many
production systems rely upon nil exceptions during Kernel.get_in calls for
proper behavior that would fail if we made it nil-safe by default.
-Greg Vaughn
> On Feb 7, 202
e: 23}}
iex> get_in(users, ["unknown", :age])
nil
The Access module guarantees no nil-safety. It's an "accident" that Access.get
does.
-Greg Vaughn
> On Feb 7, 2020, at 4:40 PM, José Valim wrote:
>
> Hi Greg, I have been thinking more about this too,
untrusted input. I don't want to write an `if` or `with` dealing with each list
key that might be nil, when I don't have to do it for maps. It it is the very
reason I view the dot syntax as very confident keys exist vs. a get_in call
which uses Access to determine existence of keys/lists.
-Greg
nil
(elixir) lib/access.ex:663: Access.at/4
I propose that the function returned from Access.at/1 special case nil such
that the overall get_in/2 call returns nil instead of raising an error. I have
not dug into the source yet but I'm happy to work up a PR if there is interest
in this change
tently nil safe. I'm open to
more ideas, too.
-Greg Vaughn
> On Jan 28, 2020, at 12:45 PM, José Valim wrote:
>
> The proposal is reasonable however it would introduce an inconsistency since
> the other selectors in Access, such as Access.key, are also not nil safe. So
> whatever
n't solve
it. I'm afraid I haven't explained the situation well enough. If get_in cannot
navigate the path to the value specified, I don't want it to raise. I'd prefer
it return nil, but :error would also be acceptable (or an optional `default`
parameter). In my situation the inability to n
(:final_key]))
Example fully lax:
get_in(data, [:key, Access.nth(0), :other_key, Access.nth(0), :final_key])
-Greg Vaughn
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving
tps://hexdocs.pm/elixir/1.10.4/Protocol.html#module-reflection
-Greg Vaughn
> On Sep 26, 2020, at 5:25 PM, thia.md...@gmail.com
> wrote:
>
> Currently we have in the stdlib Protocol.assert_impl!/2 that raises an
> exception if the given module does not implement the protocol.
&
Any expression is allowed in the comma-separated steps of a with expression.
You can put in IO.inspect(myvar) (which I often use for debugging purposes). A
pattern match (=) is an allowed expression. It is not a bug.
-Greg Vaughn
> On Aug 12, 2020, at 7:42 PM, Bruno Rafael wrote:
>
&
I have not thought about this in a while. I don't immediately see those new
functions as something I'd use. They push extra burden on the client programmer
to know all the corner cases and protect from them. I always envisioned
`get_in` as something like searching an html document via a css
If this is related to the mystery benchmark tweets, José, then I guess I'm in
favor of the proposal :-)
I do prefer Felipe's name of `Enum.indexed/1` though. While `index` can be a
verb, it's ambiguous with the noun. `indexed` is clearly a past tense verb.
-Greg Vaughn
> On Dec 8, 2020, a
I really like the idea of a convenience function in the Keyword module. One
idea that comes to mind:
Keyword.limit_keys!([parentheses: 10], [:parenthesis])
raises or returns 1st param unchanged.
-Greg
> On Dec 30, 2020, at 4:53 AM, José Valim wrote:
>
> The issue is that for take!, I can see
) It's hostile to newcomers to Elixir. Often Elixir is also their first
functional language. The proposal requires a solid knowledge of higher order
functions in order to do some very basic things a beginner would see in an
early tutorial.
-Greg Vaughn
--
You received this message because you
This can be accomplished by using a `with` in which the `else` clause is the
good result. Readability is up for debate of course.
with :error <- Map.fetch(states, abbreviation), do: {:error, "State not found"}
-Greg Vaughn
> On Jan 26, 2021, at 3:50 PM, Jonathan Arnett
I am so impressed with how long the background processes in your brain live,
José :-)
You don't need my review, but the commit looks :thumbsup: to me.
-Greg Vaughn
> On Apr 2, 2021, at 11:41 AM, José Valim wrote:
>
> After coming to this issue a couple times, I believe we shou
"namespace".
I'm slightly disappointed that the old style `reduce:` option will be
deprecated (because I have old code I'll have to update) however, the change
does make things more consistent and I appreciate the thought about future
extensions to for comprehensions.
-Greg Vaughn
PS. I ju
nt" when a new concept fits
together in your mind. Google for terms such as "expression based language" for
more details.
That being said, yes, this insight offers you a deeper way of looking at
conditional logic in Elixir. However, a ternary operator is distinct, as José
pointed out
31 matches
Mail list logo
