[#100309] How to use backport custom field — Jun Aruga <jaruga@...>
Please allow my ignorance.
9 messages
2020/10/06
[#100310] Re: How to use backport custom field
— "NARUSE, Yui" <naruse@...>
2020/10/06
IkJhY2twb3J0IGN1c3RvbSBmaWVsZCIgaXMgb25seSBhdmFpbGFibGUgZm9yIHRpY2tldHMgd2hv
[#100311] Re: How to use backport custom field
— Jun Aruga <jaruga@...>
2020/10/06
On Tue, Oct 6, 2020 at 4:44 PM NARUSE, Yui <[email protected]> wrote:
[#100314] Re: How to use backport custom field
— "NARUSE, Yui" <naruse@...>
2020/10/06
VGhhbmsgeW91IGZvciBjb25maXJtYXRpb24uCkkgY2hlY2tlZCBhZ2FpbiBhbmQgdG8gZWRpdCBi
[#100322] Re: How to use backport custom field
— Jun Aruga <jaruga@...>
2020/10/07
On Tue, Oct 6, 2020 at 7:25 PM NARUSE, Yui <[email protected]> wrote:
[#100326] Re: How to use backport custom field
— "NARUSE, Yui" <naruse@...>
2020/10/07
SSBhZGRlZCB5b3UgdG8gIlJlcG9ydGVyIiByb2xlIGluIHRoZSBwcm9qZWN0CgoyMDIw5bm0MTDm
[#100327] Re: How to use backport custom field
— Jun Aruga <jaruga@...>
2020/10/07
On Wed, Oct 7, 2020 at 1:42 PM NARUSE, Yui <[email protected]> wrote:
[ruby-core:100498] [Ruby master Feature#17265] Add `Bool` module
From:
shevegen@...
Date:
2020-10-22 10:41:57 UTC
List:
ruby-core #100498
Issue #17265 has been updated by shevegen (Robert A. Heiler).
I tried to make a shorter summary of my thoughts here, so just three points=
- hopefully that makes it easier to read:
(1) Most of the discussion, I think, happened at https://github.com/ruby/rb=
s/issues/133 - if I then understand the discussion correctly then it would =
mean that ruby would have to add "module Bool" or "module Boolean".
(2) One slight problem I see with that is that a use case originating (most=
ly) from RBS, even if it makes sense from the point of view of RBS, would p=
otentially effect change in MRI ruby. I don't have a strong opposing opinio=
n per se, but I think it would be better if the use case would be from MRI =
directly, rather than the other way around. See also headius' comment in an=
other issue about other implementations potentially affecting MRI via tests=
/specifications. I am not involved in test/specs but I understood what head=
ius meant here. This is one reason why I think it should be considered care=
fully whether change is really necessary in this regard. Keep also in mind =
that when a "module Bool / Boolean" exists in ruby, new users may ask how t=
his should then be used, and it may be a bit complicated if the explanation=
is "because RBS uses it", even more so if these users may not need or use =
RBS (not everyone will use types; some may but others may not).
(3) I know way too little about the internals (admittedly I am not clever e=
nough for high level C, and I am not even kidding here), but if the use cas=
e is primarily originating from RBS itself, could there be not another, ind=
irect solution? For example, rather than requiring a change in MRI, could t=
here not be some kind of meta-VM instead, that could be targeted? A bit lik=
e rubocop too, perhaps, for RBS? That way people could set it up for their =
own projects, adjust it as needed, and "simulate" as if a boolean "type" we=
re to exist, without MRI needing to add a module, sort of where you just we=
re to "simulate" that a boolean value exists. Again, I am not sure if this =
makes any sense what I write, but perhaps it would be better to wait some t=
ime, see how RBS shapes up, how the use cases may change, and then re-evalu=
ate in say, two years or so. There are already quite a lot of changes if we=
look at the ruby-jit, ractor and so forth - it may be more clear how RBS m=
ay have to change (or effect change) in a little while.
----------------------------------------
Feature #17265: Add `Bool` module
https://bugs.ruby-lang.org/issues/17265#change-88118
* Author: marcandre (Marc-Andre Lafortune)
* Status: Open
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
----------------------------------------
1-line Summary: `rbs` would benefit from the existence of common ancestor `=
Bool` for `TrueClass` and `FalseClass`.
Detail:
Matz: I am aware you rejected a similar request, but could we revisit this =
in light of RBS?
One use case was for an easy way to check for `true` or `false` values, ins=
tead of simply for truthiness (e.g. for data transfer, strict argument chec=
king, testing, etc.)
I believe there's a new use case: `RBS`
In `RBS`, the most used types like `String` and `Integer` have types for "s=
tring-like" and "integer-like" objects: `string` and `integer` (all lowerca=
se).
For example the signature for `Integer#>>` is:
```
def >>: (int) -> Integer
```
It accepts an `Integer` *or an object responding to `to_int`* (summarized b=
y `int`) and returns an `Integer` (and never another class of object respon=
ding to `to_int` or not).
There is a similar idea with boolean values, where a method may accept any =
object and will use it's truthiness, while returning `true | false`. For ex=
ample one of the interface for `Enumerable#all?` should look like:
```
def all?: () { (Elem) -> bool } -> true | false
```
The user supplied block can return any value, and its truthiness (anything =
else than `nil` or `false`) will be used to determine the result of `all?`.=
That result will be `true | false`, and no other value.
If RBS is to be popular, there will be *many* signatures for such predicate=
s (in builtin Ruby, stdlib, any gems, applications, etc.). I feel the best =
option would be `Bool`, if this would be reflected in Ruby itself.
Proposal: a new global module called `Bool`, without any method of constant=
, included in `TrueClass` and `FalseClass`.
Following reasons for rejection were given at the time:
> many gems and libraries had already introduced Boolean class. I don't wan=
t to break them.
I looked and found the [`bool` gem](https://rubygems.org/gems/bool) that de=
fines a `Bool` module. My proposal is compatible. In any case, this gem loo=
ks abandoned, the author Aslak Helles=F8y doesn't have the code on github, =
the gem has had 7000 downloads in the past 6 years and [has no public rever=
se dependency](https://rubygems.org/gems/bool/reverse_dependencies). It als=
o fails to install on my machine.
I am not aware of incompatibilities.
> `true` and `false` are the only representative of true-false values. In =
Ruby. `nil` and `false` are falsy values, and everything else is a true val=
ue. There's no meaning for having a superclass of `TrueClass` and `FalseCla=
ss` as `Boolean`.
The proposal is exactly to be able to easily write about this duality of `B=
ool` as having only `true` and `false` as members, and every Ruby object as=
being implicitly convertible as being truthy or falsy (`bool` in RBS).
Discussion in RBS:
* https://github.com/ruby/rbs/issues/133
Previous feature requests for `Boolean`:
* https://bugs.ruby-lang.org/issues/14224
* https://bugs.ruby-lang.org/issues/12515
-- =
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:[email protected]?subject=3Dunsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>