[#114936] [Ruby master Feature#19908] Update to Unicode 15.1 — "nobu (Nobuyoshi Nakada) via ruby-core" <ruby-core@...>

Issue #19908 has been reported by nobu (Nobuyoshi Nakada).

24 messages 2023/10/02

[#115016] [Ruby master Bug#19921] TestYJIT#test_bug_19316 test failure — "vo.x (Vit Ondruch) via ruby-core" <ruby-core@...>

Issue #19921 has been reported by vo.x (Vit Ondruch).

21 messages 2023/10/12

[#115033] [Ruby master Misc#19925] DevMeeting-2023-11-07 — "mame (Yusuke Endoh) via ruby-core" <ruby-core@...>

Issue #19925 has been reported by mame (Yusuke Endoh).

12 messages 2023/10/13

[#115068] [Ruby master Bug#19929] Warnings for `mutex_m`, `drb` and `base64` appears while the gem spec has explicit dependencies — "yahonda (Yasuo Honda) via ruby-core" <ruby-core@...>

Issue #19929 has been reported by yahonda (Yasuo Honda).

8 messages 2023/10/17

[#115071] [Ruby master Misc#19931] to_int is not for implicit conversion? — "Dan0042 (Daniel DeLorme) via ruby-core" <ruby-core@...>

Issue #19931 has been reported by Dan0042 (Daniel DeLorme).

16 messages 2023/10/17

[#115139] [Ruby master Bug#19969] Regression of memory usage with Ruby 3.1 — "hsbt (Hiroshi SHIBATA) via ruby-core" <ruby-core@...>

Issue #19969 has been reported by hsbt (Hiroshi SHIBATA).

8 messages 2023/10/24

[#115165] [Ruby master Bug#19972] Install default/bundled gems into dedicated directories — "vo.x (Vit Ondruch) via ruby-core" <ruby-core@...>

Issue #19972 has been reported by vo.x (Vit Ondruch).

11 messages 2023/10/25

[#115196] [Ruby master Feature#19979] Allow methods to declare that they don't accept a block via `&nil` — "ufuk (Ufuk Kayserilioglu) via ruby-core" <ruby-core@...>

Issue #19979 has been reported by ufuk (Ufuk Kayserilioglu).

21 messages 2023/10/29

[ruby-core:115177] [Ruby master Feature#8520] Distinct to_s methods for Array, Hash...

From: "p8 (Petrik de Heus) via ruby-core" <ruby-core@...>
Date: 2023-10-26 09:41:59 UTC
List: ruby-core #115177
Issue #8520 has been updated by p8 (Petrik de Heus).





There is an open issue in Rails to limit `ActiveRecord::Base#inspect` for p=
erformance reasons.

https://github.com/rails/rails/issues/49707



Calling `to_s` on a `Hash` will call `inspect` on its contents.

`ActiveRecord::Base#inspect` prints all the records attributes. It loops th=
rough all attributes and filters sensitive ones.

So calling `to_s` on a `Hash` with a lot of ActiveRecord instances/attribut=
es can result in performance issues, as it filters all attributes.



Of course this issue can be fixed in Rails by changing `ActiveRecord::Base#=
inspect`, or not calling to `to_s` on a large `Hash`.

But it might not be obvious to everyone that `Hash#to_s` is an alias to `Ha=
sh#inspect`, as a lot of objects have different behaviour for `to_s` and `i=
nspect`.





----------------------------------------

Feature #8520: Distinct to_s methods for Array, Hash...

https://bugs.ruby-lang.org/issues/8520#change-105092



* Author: LFDM (Gernot H=F6flechner)

* Status: Feedback

* Priority: Normal

* Assignee: matz (Yukihiro Matsumoto)

----------------------------------------

I apologize if something like this has already been proposed in the past, i=
f it was, I can't find it at the moment.



Ruby 2.0 rightfully changed to behaviour of inspect (not delegating to to_s=
 anymore), as inspect was effectively disabled when you had custom to_s met=
hods implemented.



However I think that a mix of the old and the new would combine the best of=
 both worlds.

Array or Hash to_s methods should not delegate to inspect, but instead refl=
ect the old behavior and call to_s to all members of a given collection.



Use Case:

I am currently designing a fairly large application that constructs very co=
mplex objects. For debugging reasons those objects have to_s methods implem=
ented to read terminal output in a digestible format.

In constructing these to_s methods it was very convenient to string-interpo=
late collections of such objects.

A quick example:



class A

  def initialize

    @a =3D "Large example text"

  end



  def to_s

    # abbreviated form

    @a[0]

  end

end



arr =3D []

5.times { arr << A.new }

arr << arr.clone



puts "#{arr}"



Ruby 1.9.3 output: [L, L, L, L, L, [L, L, L, L, L]]

Ruby 2.0.0.output: [#<A:0x00000001f52c50 @a=3D"Large example text">, #<A:0x=
00000001f52c00 @a=3D"Large example text">, #<A:0x00000001f52bb0 ... and muc=
h more



I deliberately nested the example - as it obstructs the use of a simple joi=
n (arr * " " =3D> L L L L L L L L L L), which cannot reflect the array's ne=
sting.

Printing a hash would be even more difficult - and with more nesting this b=
ecomes an immense task.



Of course someone could just adjust the to_s method, but the elegance gets =
lost, logging something like this would quickly lead to not so pretty code:

"The array looked like: #{arr}"



So I'd say distinct to_s methods, that call to_s recursively instead of del=
egating to inspect. Basically leaving inspect at its correct 2.0 behavior a=
nd reverting to_s (and thus #{}) back to its 1.9 behaviour.

Let's hope I am not overlooking something here.



What do you think?

Thanks for your feedback in advance,

GH







--=20

https://bugs.ruby-lang.org/

 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-c=
ore.ml.ruby-lang.org/

In This Thread

Prev Next