From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: poffice@blade.nagaokaut.ac.jp Delivered-To: poffice@blade.nagaokaut.ac.jp Received: from kankan.nagaokaut.ac.jp (kankan.nagaokaut.ac.jp [133.44.2.24]) by blade.nagaokaut.ac.jp (Postfix) with ESMTP id A531919600C2 for ; Wed, 8 Jul 2015 21:33:49 +0900 (JST) Received: from funfun.nagaokaut.ac.jp (smtp.nagaokaut.ac.jp [133.44.2.201]) by kankan.nagaokaut.ac.jp (Postfix) with ESMTP id 794F7B5D927 for ; Wed, 8 Jul 2015 22:00:52 +0900 (JST) Received: from funfun.nagaokaut.ac.jp (localhost.nagaokaut.ac.jp [127.0.0.1]) by funfun.nagaokaut.ac.jp (Postfix) with ESMTP id 1821B97A856 for ; Wed, 8 Jul 2015 22:00:55 +0900 (JST) X-Virus-Scanned: amavisd-new at nagaokaut.ac.jp Authentication-Results: funfun.nagaokaut.ac.jp (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=sendgrid.me Received: from funfun.nagaokaut.ac.jp ([127.0.0.1]) by funfun.nagaokaut.ac.jp (funfun.nagaokaut.ac.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsT_uGzm5htf for ; Wed, 8 Jul 2015 22:00:54 +0900 (JST) Received: from voscc.nagaokaut.ac.jp (voscc.nagaokaut.ac.jp [133.44.1.100]) by funfun.nagaokaut.ac.jp (Postfix) with ESMTP id 7698097A855 for ; Wed, 8 Jul 2015 22:00:54 +0900 (JST) Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by voscc.nagaokaut.ac.jp (Postfix) with ESMTP id 9179E95243E for ; Wed, 8 Jul 2015 22:00:51 +0900 (JST) Received: from [221.186.184.76] (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id C4A9812045F; Wed, 8 Jul 2015 22:00:49 +0900 (JST) X-Original-To: ruby-core@ruby-lang.org Delivered-To: ruby-core@ruby-lang.org Received: from o10.shared.sendgrid.net (o10.shared.sendgrid.net [173.193.132.135]) by neon.ruby-lang.org (Postfix) with ESMTPS id 07FD4120433 for ; Wed, 8 Jul 2015 22:00:45 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.me; h=from:to:references:subject:mime-version:content-type:content-transfer-encoding:list-id; s=smtpapi; bh=RR64mCOJrm80Tlyr95houLh6SZ0=; b=P6Jgf+UY9AfL1L3/Td l5BSS+RbPPlAt6nt246VtKZDV9kbFdEe+ZFo/BAVARJzFPofAgr1Ax/dWsykoeHz 3tWKI4Krj3uwHtEq2VODYsuUKlPeqDH1NeI29iizn+KTSnhvrXX0t1nqmc5/gonU rhaaLXHwTsGVlnTNEl0lC63g8= Received: by filter0824p1mdw1.sendgrid.net with SMTP id filter0824p1mdw1.11769.559D1EF612 2015-07-08 13:00:38.298371786 +0000 UTC Received: from herokuapp.com (ec2-54-162-185-52.compute-1.amazonaws.com [54.162.185.52]) by ismtpd-028 (SG) with ESMTP id 14e6dc0f20f.1bf.202d46 Wed, 08 Jul 2015 13:00:38 +0000 (UTC) Date: Wed, 08 Jul 2015 13:00:38 +0000 From: nerdinand@nerdinand.com To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Redmine-MailingListIntegration-Message-Ids: 44511 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 10594 X-Redmine-Issue-Author: findchris X-Redmine-Sender: nerdinand X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS4tR655DKcJy1ta1dkDO6xxgNEEt9M32A/PFJ R/MErWFSK2/+QhDFxcQhly/Z2fdx9jGNX6mZyyKvgjsfwkw4zUG3ko2vnsc0y4foQxIg3ZqFYUiYC4 UHkApFbwzE+NukTWh6E9Ic5Fxr4riARG9k8m X-ML-Name: ruby-core X-Mail-Count: 69901 Subject: [ruby-core:69901] [Ruby trunk - Bug #10594] Numeric#clamp X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #10594 has been updated by Ferdinand Niedermann. I think there is even another option: Swapping the min and max values if they are passed in the wrong order. This is obviously a question of the principle of least surprise. If you compare `#clamp` to `#between?`, it makes sense to actually return something instead of raising, because `#between?` does the same. But as you say, one could argue that it's best to catch the error as early as possible, so raising would be a good option. The only thing I definitely would not agree with is returning the receiver, as that is a valid behaviour if the receiver is between `min` and `max`. I think it would lead to confusion. ---------------------------------------- Bug #10594: Numeric#clamp https://bugs.ruby-lang.org/issues/10594#change-53319 * Author: Chris Johnson * Status: Open * Priority: Normal * Assignee: * ruby -v: 2.1.2 * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN ---------------------------------------- This is basically a re-opening of the feature request of issue#4573 (https://bugs.ruby-lang.org/issues/4574), which was closed due a naming debate. It seems the standard naming for restricting a number to a specified range is indeed 'clamp'. (1)(2)(3) As such, can we use Yusuke Endoh's original patch with the naming adjustments? If so, I can provide accordingly. Cheers. (1) http://www.rubydoc.info/github/epitron/epitools/Numeric:clamp (2) http://stackoverflow.com/questions/12020787/is-there-a-limit-clamp-function-in-ruby (3) https://developer.gnome.org/glib/stable/glib-Standard-Macros.html#CLAMP:CAPS ---Files-------------------------------- num_clamp.c (427 Bytes) -- https://bugs.ruby-lang.org/