From: me@iotaspencer.me
To: ruby-core@ruby-lang.org
Subject: [ruby-core:86554] [Ruby trunk Feature#13683] Add strict Enumerable#single
Date: Mon, 16 Apr 2018 22:45:46 +0000 (UTC) [thread overview]
Message-ID: <redmine.journal-71494.20180416224545.c5cfa2feacfce665@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-13683.20170627060807@ruby-lang.org
Issue #13683 has been updated by IotaSpencer (Ken Spencer).
matz (Yukihiro Matsumoto) wrote:
> Hmm, I don't like the name `single`. Besides that, I think it may be useful for database access, but I don't see the use-case of this method for generic Enumerable.
>
> Matz.
I think of single as a method towards mutual exclusivity.
If an Array or Enumerable from another expression should only have a single element,
then this gives the process a much faster setup and possible rescue, as I currently have
one of my projects checking for the existence of 3 headers, `X-GitHub-Event`, `X-GitLab-Event`,
and `X-Gogs-Event`, and I found the easiest way was to use `one` from Enumerable, but I wanted it
to error out so that I could catch it with the rest of my raised exceptions from other errors that
arise in the handling of the request.
How about these for suggestions.
`one_or_raise`
`one_or_nothing`
Part of my code for context.
~~~ ruby
events = {'github' => github, 'gitlab' => gitlab, 'gogs' => gogs
}
events_m_e = events.values.one?
case events_m_e
when true
event = 'push'
service = events.select { |key, value| value }.keys.first
when false
halt 400, {'Content-Type' => 'application/json'}, {message: 'events are mutually exclusive', status: 'failure'
}.to_json
else halt 400, {'Content-Type' => 'application/json'}, {'status': 'failure', 'message': 'something weird happened'
}
end
~~~
----------------------------------------
Feature #13683: Add strict Enumerable#single
https://bugs.ruby-lang.org/issues/13683#change-71494
* Author: dnagir (Dmytrii Nagirniak)
* Status: Feedback
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
### Summary
This is inspired by other languages and frameworks, such as LINQ's [Single](https://msdn.microsoft.com/en-us/library/bb155325%28v=vs.110%29.aspx) (pardon MSDN reference), which has very big distinction between `first` and `single` element of a
collection.
- `first` normally returns the top element, and the developer assumes
there could be many;
- `single` returns one and only one element, and it is an error if there
are none or more than one.
We, in Ruby world, very often write `fetch_by('something').first`
assuming there's only one element that can be returned there.
But in majority of the cases, we really want a `single` element.
The problems with using `first` in this case:
- developer needs to explicitly double check the result isn't `nil`
- in case of corrupted data (more than one item returned), it will never
be noticed
`Enumerable#single` addresses those problems in a very strong and
specific way that may save the world by simply switching from `first` to
`single`.
### Other information
- we may come with a better internal implementation (than `self.map`)
- better name could be used, maybe `only` is better, or a bang version?
- re-consider the "block" implementation in favour of a separate method (`single!`, `single_or { 'default' }`)
The original implementation is on the ActiveSupport https://github.com/rails/rails/pull/26206
But it was suggested to discuss the possibility of adding it to Ruby which would be amazing.
--
https://bugs.ruby-lang.org/
next prev parent reply other threads:[~2018-04-16 22:45 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <redmine.issue-13683.20170627060807@ruby-lang.org>
2017-06-27 6:08 ` [ruby-core:81779] [Ruby trunk Bug#13683] Add strict Enumerable#single dnagir
2017-06-27 10:18 ` [ruby-core:81788] [Ruby trunk Feature#13683] " eregontp
2017-06-27 20:05 ` [ruby-core:81793] " shevegen
2017-06-27 21:41 ` [ruby-core:81794] " Matthew Kerwin
2017-06-27 23:19 ` [ruby-core:81796] " mame
2017-06-28 1:15 ` [ruby-core:81798] " shannonskipper
2017-06-28 6:22 ` [ruby-core:81803] " nobu
2017-06-30 13:57 ` [ruby-core:81874] " dnagir
2017-06-30 14:01 ` [ruby-core:81875] " dnagir
2017-07-24 0:26 ` [ruby-core:82140] " johncbackus
2017-09-25 9:05 ` [ruby-core:82983] [Ruby trunk Feature#13683][Feedback] " matz
2018-04-16 22:45 ` me [this message]
2018-04-24 12:40 ` [ruby-core:86665] [Ruby trunk Feature#13683] " nobu
2018-07-26 20:40 ` [ruby-core:88129] " shannonskipper
2019-04-02 16:11 ` [ruby-core:92111] " lisa.ugray
2019-10-06 20:14 ` [ruby-core:95250] [Ruby master " jonathan
2019-10-07 2:23 ` [ruby-core:95254] " daniel
2019-10-17 5:59 ` [ruby-core:95382] " matz
2019-10-17 6:24 ` [ruby-core:95384] " ppyd
2019-10-17 7:24 ` [ruby-core:95388] " hanmac
2019-10-17 17:55 ` [ruby-core:95399] " daniel
2019-11-13 16:04 ` [ruby-core:95845] " kuchenbecker.k
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.ruby-lang.org/en/community/mailing-lists/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=redmine.journal-71494.20180416224545.c5cfa2feacfce665@ruby-lang.org \
--to=ruby-core@ruby-lang.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).