<link rel="self" href="https://bugs.ruby-lang.org/issues/14801.atom"/> <link rel="alternate" href="https://bugs.ruby-lang.org/"/> <id>https://bugs.ruby-lang.org/</id> <icon>https://bugs.ruby-lang.org/favicon.ico?1595023789</icon> <updated>2018-06-01T09:45:00Z</updated> <author> <name>Ruby Issue Tracking System</name> </author> <entry> <title>Ruby master - Feature #14801: New method 'show_stack' to show Ruby stack(s) when program is running https://bugs.ruby-lang.org/issues/14801?journal_id=72334 2018-06-01T09:45:00Z shevegen (Robert A. Heiler) shevegen@gmail.com <ul></ul><p>A bit of feedback as asked by Martin; I&#39;ll skip the implementation detail part since<br> I do not know C so others have to comment on that part.</p> <ul> <li><p>The name: I think the name is ok in &quot;itself&quot;, that is, if we see &quot;show_stack&quot;,<br> we can understand what is meant. That it can work on e. g. an Integer is a bit<br> weird though, such as 6.show_stack. Perhaps it may be better to have it a bit<br> more verbose and reside on Kernel.show_stack(6) or some other default ruby <br> module (a bit like RbConfig or RubyVM so... perhaps a new one.) But anyway, I<br> think the name part is separate from the functionality, and I think the <br> functionality is fine. I love introspection so just about every change to <br> provide us with more information is good, IMO.</p></li> <li><p>As for built-in or gem, I agree that it would be better to have it within<br> ruby core itself. There were other discussions about other changes and people<br> providing reasons as to why something should be a gem or part of the<br> stdlib/core. For example, since ruby is so flexible (duck typing and duck<br> patching and doing all about the ducklings), additional functionality could<br> be easily put into a gem and loaded /or removed) at will. For me, personally,<br> having something part of core/stdlib, is good for two reasons:</p></li> <li><p>Just about everyone will have this functionality, which can be really <br> helpful when distributing code. This is, for me, also a reason why I think<br> the bundler integration was good - I myself do not use bundler, but I <br> understand the rubygem team not wanting to duplicate functionality when<br> bundler provides it, and vice versa. So from this point of view, having<br> functionality within ruby core/stdlib is very, very useful.</p></li> <li><p>The other reason is a bit more from a design point of view. When changes<br> are made, we can know that matz has approved of them. So that is a good<br> thing IMO since it is a part of quality control too; in other words, to<br> be ruby ruby.</p></li> </ul> <blockquote> <p>I implemented RubyVM.show_stack before I realized that Object#show_stack<br> would be needed, so it&#39;s still there, but may now be superfluous.</p> </blockquote> <p>Strange. I would think that .show_stack fits better to RubyVM than Object.<br> But I guess matz can comment at the next developer meeting perhaps.</p>