Feature #19559: Introduce `Symbol#+@` and `Symbol#-@`, and eventually replace boolean arguments with symbols

• Status: Rejected
• Assignee: -
• Target version: -

[sawa (Tsuyoshi Sawada)]

I propose to define Symbol#+@ and Symbol#-@, so that we can add positive or negative polarity to symbols. A possible implementation can be equivalent to what can be achieved by this:

class Symbol
  def -@; "-#{self}".to_sym end
  def +@; self end
end

The intention behind this is to, eventually, replace boolean positional or keyword arguments with symbols so that, instead of this:

"foo".methods(false)

gets(chomp: true)

Integer("2.3", exception: false)

we can write like this:

"foo".methods(-:inherit)

gets(+:chomp)

Integer("2.3", -:exception)

[baweaver (Brandon Weaver)]

While I like the goal of potentially more succinct boolean arguments I think this will be confusing and difficult to locate documentation for.

[austin (Austin Ziegler)]

What would be the result of the pathological cases?

+:"-chomp"
-(-:chomp)

With the proposed implementation, it would be :"-chomp" and :"--chomp", but those both feel wrong.

If we wanted to accept non-keyword arguments for gets and Integer, I would support more :no_chomp or :no_exxception.

Unless of course, this is a very early poisson d’Avril, in which case I think we need to have more unary operators on symbols so we can implement BF entirely with symbols.

[sawa (Tsuyoshi Sawada)]

@austin (Austin Ziegler) -(-:chomp) would simply be invalid just like when you pass some random symbol there :some_random_symbol that is not expected there. And why would you write +:"-chomp"? There is no point in doing that. In the first place, as I wrote, the implementation is just to illustrate the idea and is not meant to describe the details. The point is that, Symbol#-@ should map the symbol to something distinguishable while retaining the information of the original symbol. At first, I though of letting Symbol#-@ map the receiver to a subclass of symbol with the same content, but gave up on that because I could not come up with a way to construct an instance of the subclass.

Unless of course, this is a very early poisson d’Avril, in which case I think we need to have more unary operators on symbols so we can implement BF entirely with symbols.

I strongly urge you to remove that sentence or your entire comment.

[vo.x (Vit Ondruch)]

One of the benefits or Ruby used to be readability. There were great times when Integer("2.3", :exception => false) was standard. Than came the JS hash notation Integer("2.3", exception: false) which have not improved the situation and now this Integer("2.3", -:exception)?

IOW I am against this proposal, because it will make the code less readable.

[rubyFeedback (robert heiler)]

I think the idea is interesting; it also helps reduce the number of characters
used. mame may like it for golf code. :)

I do, however had, also think this may create a few issues. One I can think of
the top of the head may be that newcomers to ruby may be a bit confused by the
syntax.

For instance:

"foo".methods(false)

Seems simpler to understand than:

"foo".methods(-:inherit)

(I understand that one can disagree here, since the second variant given by
sawa carries additional information, in that there is a symbol given or
symbol-like information given, e. g. the ":inherit" part. Whereas in the
first example, one needs to understand that "false" or "true" has a different
meaning within the context of the method at hand that is invoked.)

I also think the "-:" and "+:" is not extremely elegant. This, of course,
depends on one's preference about elegant syntax. It may also be a bit
confusing in regards to class String and +/- de-dup. Not sure about that,
I kind of avoid the shorthand there, and just do:

x = x.dup if x.frozen? # or something like that.

But the idea itself is still interesting.

austin wrote:

Unless of course, this is a very early poisson d’Avril, in which case
I think we need to have more unary operators on symbols so we can
implement BF entirely with symbols.

We could group that into oldschool evil.rb. All the weird parts of ruby
that didn't quite manage to be approved by matz, but may still be added. :D

Although perhaps it may be better to add as a gem or some other add-on.
Kind of where you can be super-flexible and adjust ruby to really very
awkward use cases, whereas "main stay ruby" is kept in a "inner consistency"
state by matz (e. g. approve/reject on proposals that fit, or don't fit,
correspondingly).

Vit wrote:

One of the benefits or Ruby used to be readability.

Agreed. :)

I do still think ruby is readable. This, of course, depends on who writes ruby.

For instance, zverok has a lot of awesome projects and a unique style. To me,
personally, I find that style more difficult to understand (it is more
"functional" centric; I am more leaning towards a OOP style, in the Alan Kay
"oldschool" tradition and I try to keep things simple but expressive, a bit
like "succinct english prose", if that is possible).

Vit wrote:

There were great times when Integer("2.3", :exception => false) was
standard. Than came the JS hash notation Integer("2.3", exception: false)
which have not improved the situation and now this Integer("2.3", -:exception)

I don't see these two necessarily be combined. But, on the shorthand
syntax inspired by JS: while I agree that the oldschool way is more
logical, e. g. the :exception => false situation, I actually use the
shorthand notation a LOT these days. More than the "real" variant.

The primary reason for that is because it's really shorter and even
easier to read (the latter may be subject to debate, but I think we
may agree that it is shorter to write). By the way, I am not entirely
certain this was solely inspired by JS - I think the rails ecosystem
also kind of encouraged that or liked it, if I remember correctly.

Anyway, I think we should separate suggestions and discussions about
suggestions. The shorthand hash notation, in my opinion, is separate
to the proposal here. As said I agree about "syntax matters", but we
can extend this to all syntax changes made - the -> lambda notation,
the .? safeguard operator or what the name was, case/when pattern
matching and so forth. In my own gems I tend to adhere to what I like,
and rigidly reject what I dislike. Ruby is more flexible than many
other programming languages; this is an advantage and a disadvantage.
(Elegant DSLs out-of-the-box is a big advantage, for instance. Ugly
syntax is, of course, a disadvantage, but even this depends on one's
point of view.)

[mame (Yusuke Endoh)]

rubyFeedback (robert heiler) wrote in #note-5:

mame may like it

No

[matz (Yukihiro Matsumoto)]

• Status changed from Open to Rejected

Giving :"-exception" symbol (plain) argument a meaning exception: false keyword argument is inconsistent. Making a few less strokes does not justify this weirdness.

Matz.

[sawa (Tsuyoshi Sawada)]

@austin (Austin Ziegler) (Austin Ziegler) I see that you have logged in. I strongly urge you to remove that sentence or your entire comment.

[austin (Austin Ziegler)]

sawa (Tsuyoshi Sawada) wrote in #note-8:

@austin (Austin Ziegler) (Austin Ziegler) I see that you have logged in. I strongly urge you to remove that sentence or your entire comment.

No. I’m not sure what you find objectionable in my (seriously) not being clear whether your proposal was a serious one or an early April Fool’s proposal, because it could have been either one. As a serious proposal, I dislike it. As joke proposal, I think that it’s entirely funny.

[sawa (Tsuyoshi Sawada)]

Dear moderators

Please ban user austin (Austin Ziegler).

[austin (Austin Ziegler)]

sawa (Tsuyoshi Sawada) wrote in #note-10:

Dear moderators

Please ban user austin (Austin Ziegler).

I object. I would like to know why I’m being asked to remove something that is not offensive or objectionable.

This is completely inappropriate for someone who has been a productive member of the Ruby community for more than twenty years.

[matz (Yukihiro Matsumoto)]

I don't see any problem in Austin's comment (#note-2) neither. Probably there's some misunderstanding (lost in translation?).
If @sawa (Tsuyoshi Sawada) has any further comment or complaint, contact us in Japanese.

Matz.

[sawa (Tsuyoshi Sawada)]

@matz (Yukihiro Matsumoto) 真剣な提案に対して、エイプリルフールネタである可能性を言い出し、貶めているという点で攻撃的です。百歩譲って、エイプリルフールネタであるという可能性がこの人の脳裏に浮かび、どちらとして対処したら良いのか迷ったとしましょう。もし仮にエイプリルフールネタであったとして、それを真面目な提案としてコメントを付けたとしても痛みはありません。逆に、今回のように真面目な投稿に対してエイプリルフールネタであるかもしれないことを言及するのは、極めて失礼なことです。さらに両方の可能性を併記する必要など全くありません。

書いてしまったあとでも、その後の私のコメントで、真面目な投稿であることは分かったはずなのですから、その時点で、エイプリルフールネタであるかもしれないなどと言ったことを削除すればよかったのです。にも関わらず、この人は、新しいコメントで、さらにジョークに言及することを書き足し、面白おかしいなどと言って侮辱しています。

[sawa (Tsuyoshi Sawada)]

以下のコメントに付き、松本さん以外の開発者の方でも対処できる方がいれば、対処をお願いします。

[hsbt (Hiroshi SHIBATA)]

I agreed Matz's opinion.

Calm down, please.

[matz (Yukihiro Matsumoto)]

私を含めた多くの人には #note-3 で @sawa (Tsuyoshi Sawada) さんが突然怒りだしたように見えます。少なくともその時点で「真剣に提案したものをエイプリルフールジョーク扱いするのは失礼だ」と感じたことは表明しておくべきではなかったでしょうか。また、自分が真剣に提案したものがエイプリルフールジョークだと思われて傷ついたという気持ちは理解できないことはないですが、だからと言って、それに対してコメントの削除なり、追放なりを求めるのはやりすぎだと思います。「私は真剣だった」、「そうでしたか」で終わるべき対話だったと感じています。

To many people, including me, @sawa (Tsuyoshi Sawada) seemed to suddenly get angry in #note-3. At least at that point, You should have expressed that you felt it was rude to treat a serious proposal as an April Fool's joke. Also, I can understand your feeling of being hurt by someone thinking that what you seriously proposed was an April Fool's joke, but that doesn't mean you should ask for the comment to be deleted or banned. I think it's overkill. I feel that the dialogue should end with “I was serious” and “OK”.

[sawa (Tsuyoshi Sawada)]

matz (Yukihiro Matsumoto) wrote in #note-16:

You should have expressed that you felt it was rude to treat a serious proposal as an April Fool's joke. ... [T]hat doesn't mean you should ask for the comment to be deleted or banned. I think it's overkill. I feel that the dialogue should end with “I was serious” and “OK”.

@matz (Yukihiro Matsumoto) @hsbt (Hiroshi SHIBATA)
I recalled that Ruby had adopted community conduct guideline https://www.ruby-lang.org/en/conduct/, whose third point says:

When interpreting the words and actions of others, participants should always assume good intentions.

Austin (Austin Ziegler)'s comment https://bugs.ruby-lang.org/issues/19559#note-2 violates this. When commenting on a serious feature proposal, the proposal must be interpreted as a serious proposal, not as a joke. The poster of the feature should not need to particularly mention that it is not a joke. And since that comment is a violation of the conduct, it is natural that it should be deleted or banned.

[austin (Austin Ziegler)]

sawa (Tsuyoshi Sawada) wrote in #note-17:

I recalled that Ruby had adopted community conduct guideline https://www.ruby-lang.org/en/conduct/, whose third point says:

When interpreting the words and actions of others, participants should always assume good intentions.

Austin (Austin Ziegler)'s comment https://bugs.ruby-lang.org/issues/19559#note-2 violates this. When commenting on a serious feature proposal, the proposal must be interpreted as a serious proposal, not as a joke. The poster of the feature should not need to particularly mention that it is not a joke. And since that comment is a violation of the conduct, it is natural that it should be deleted or banned.

I’ve stayed out of this for the most part, but I want to address this. I was not involved in the Ruby community conduct conversations, but I have been involved in several and have pushed the adoption of a similar community conduct for our company's stance. The meaning of "always assume good intentions" does not mean what you think it means above. It means that, when having conversations, one should not assume that there are bad intentions. It does not mean that one must take every proposal entirely seriously. (It does not excuse malice disguised as humour, but there is absolutely no malicious sentiment to be found in that single sentence.)

In terms of assuming good intentions, you did not do that when you saw my response as an attack on you and your proposal. It was not. My initial response to your proposal both addressed your proposal seriously and suggested it had some humour possibilities, which was shared by other respondents. If anyone else had made a similar proposal, I probably would have responded the same way.

I am sorry that what I wrote has given offence. In the future, I shall always treat your proposals as entirely serious unless you indicate that it is, in fact, a joke proposal.

[matz (Yukihiro Matsumoto)]

The guideline should be applied both side. When you read the comment to your proposal, you should have “assumed good intentions” too.
I proposed to end this discussion.

We are sorry that your feelings were hurt, but we will not ban or delete the comment as it was due to a misunderstanding.

Matz.