Project

General

Profile

Actions

Feature #17773

open

Alias `Numeric#zero?` and `Float#zero?` as `Numeric#empty?` and `Float#empty?`

Added by sawa (Tsuyoshi Sawada) almost 3 years ago. Updated almost 3 years ago.

Status:
Open
Assignee:
-
Target version:
-
[ruby-core:103162]

Description

When dealing with user input fields as in web applications, there are typical values that we want to consider as the default and/or absence of user input. For string/text inputs, list items, and attributes, we have String#empty?, Array#empty?, and Hash#empty? respectively, which seem to correspond to those cases. As for numerics, there are Numeric#zero? and Float#zero?.

However, there is no single term that covers all these cases. In a routine to check through the fields whether there is user input, we have to selectively use empty? or zero? depending on the type of the input field.

Many programming languages other than Ruby typically consider these values as falsy with respect to logical calculation. Ruby handles only nil and false as falsy, and that has clear advantages in many aspects, but with the cost of losing a simple way to handle these default values.

I propose to alias Numeric#zero? as Numeric#empty? and Float#zero? as Float#empty? so that we can simply use empty?. At first, calling zero as empty might sound strange, but at least for non-negative integers, set theoretic definitions usually define zero as the empty set, so it is not that strange after all.

Ruby on Rails' blank? is conceptually similar to this, but 0.blank? returns false, so it is a different concept.

Actions #1

Updated by sawa (Tsuyoshi Sawada) almost 3 years ago

  • Description updated (diff)

Updated by jeremyevans0 (Jeremy Evans) almost 3 years ago

I'm against this. empty? exists on collection classes, and numbers are not collections, nor sets. Can you provide a reference to a set theoretic definition of the number 0 as the empty set? Even if so, most Ruby programmers are not working in set theory and treating numbers as sets.

If you are checking for user input, aliasing zero? to empty? seems wrong, as 0 is a valid non-empty user input. In general, if you care whether a user input was empty, you should check whether a user input string is empty before converting it to a number, instead of after.

Updated by sawa (Tsuyoshi Sawada) almost 3 years ago

jeremyevans0 (Jeremy Evans) wrote in #note-2:

Can you provide a reference to a set theoretic definition of the number 0 as the empty set?

Here is a Wikipedia article:

https://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers

Updated by sawa (Tsuyoshi Sawada) almost 3 years ago

jeremyevans0 (Jeremy Evans) wrote in #note-2:

If you are checking for user input, aliasing zero? to empty? seems wrong, as 0 is a valid non-empty user input.

I do not understand what you exactly mean by 0 is valid. But presumably, if 0 is valid in whatever sense you have in mind, then empty string is valid as well in the same sense. On the other hand, in some contexts, 0 is not valid, say, for a transfer amount in a bank transfer page, just as an empty string is not valid, say, in a required user's name field in a registration form.

On top of that, in the first place, the distinction in question is not valid vs. invalid. That is irrelevant. It is about explicit input vs. default.

[I}f you care whether a user input was empty, you should check whether a user input string is empty before converting it to a number, instead of after.

As for numeric fields, I am discussing cases where the default is 0 and the user did not change anything to the field, resulting in the return value 0. Empty string is irrelevant here.

Updated by mrkn (Kenta Murata) almost 3 years ago

I don't think these aliases are useful for most cases so it is inappropriate as a default-provided feature.
I agree there are cases that zero means empty, but there are also cases that -1 or other numbers mean empty. I don't think the zero case is the majority and special.

Updated by marcandre (Marc-Andre Lafortune) almost 3 years ago

I'm also against this proposal.

I do not believe that there are many cases where one checks for .zero? || .empty?. Note that nil nor false implement either.

If you need something like blank? or trivial? or similar, refinements are available.

Updated by Eregon (Benoit Daloze) almost 3 years ago

Same feeling here, empty? should be reserved for collections with elements.

Input fields from a website are always Strings initially, and should be checked as Strings (e.g., input.strip.empty?) for provided/not-provided.
The user might have provided "0" and that might be a correct value.

Updated by sawa (Tsuyoshi Sawada) almost 3 years ago

You may be right that zero is not (the only) special (element). In fact, one is the unit element for multiplication whereas zero is the unit element for addition. But still, addition is the first operation, and is more prominent than multiplication, which is the second operation. And the fact that we already have zero? method and the fact that many languages handle zero as falsy seem to indicate that indeed zero is special.

Regarding -1 (or other numbers) representing emptiness, I cannot recall clear instances. (Perhaps related to some sort of perpendicularity?) Can you give me some ideas?

Updated by xtkoba (Tee KOBAYASHI) almost 3 years ago

An example of using -1 as a default-ish integer value is to indicate "item not found" in a C-like language (see https://en.wikipedia.org/wiki/Sentinel_value).

The following example seems to suggest that Ruby treats 0 as a default-ish integer value in some cases.

p nil.to_i # => 0
p "".to_i # => 0

Yet I don't think that 0 should be treated as the special value in general, as long as we can freely assign both nil and an integer value to the same variable.

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0