[#82706] [Ruby trunk Bug#13851] getting "can't modify string; temporarily locked" on non-frozen instances — cardoso_tiago@...
Issue #13851 has been updated by chucke (Tiago Cardoso).
3 messages
2017/09/07
[#82853] [Ruby trunk Bug#13916] Race condition when sending a signal to a new fork — russell.davis@...
Issue #13916 has been reported by russelldavis (Russell Davis).
3 messages
2017/09/19
[#82892] [Ruby trunk Bug#13921] buffered read_nonblock doesn't work as expected using SSLSocket — cardoso_tiago@...
Issue #13921 has been updated by chucke (Tiago Cardoso).
3 messages
2017/09/20
[ruby-core:82852] [Ruby trunk Feature#13904] getter for original information of Enumerator
From:
shevegen@...
Date:
2017-09-18 23:04:24 UTC
List:
ruby-core #82852
Issue #13904 has been updated by shevegen (Robert A. Heiler). > evil things for optimization and specialization Reminds me of good old evil.rb - now I am suddenly all for it! :-) I have no particular pro or con opinion here but I think that one of ruby's philosophy is to put trust into the ruby hacker to do what he/she wants to do, e. g. duck patching modifying any of ruby's core functionality, use .send() or .instance_variable_get at leisure etc... ruby is very flexible. Encapsulation is possible but it also restricts, so it is not always ruby's philosophy. That is why, I think, .public_send() was added and people can use that for the public/private distinction. I myself love .send(), freedom to all objects and all duckling objects. \o/ By the way, the idea of composite objects reminds me a bit of what matz wrote about interface objects (specification where objects should respond to the same method-behaviour ... all ducks should be able to quack and swim ... so if something quacks and swims, even if it is a wolf disguised as a sheep, it may be treated to be an "acceptable duck"). But as said, I really am neutral here either way. :-) Perhaps the ruby core team can discuss this a bit (I don't know japanese so I do not know what thoughts are conveyed above). ---------------------------------------- Feature #13904: getter for original information of Enumerator https://bugs.ruby-lang.org/issues/13904#change-66748 * Author: znz (Kazuhiro NISHIYAMA) * Status: Open * Priority: Normal * Assignee: knu (Akinori MUSHA) * Target version: ---------------------------------------- At https://gitter.im/red-data-tools/ja?at=59b0aaa097cedeb04828e268 , mrkn says narray and pycall use internal information of ruby to check `Range#step(n)`. People of red-data-tools/ja suggest subclass of Enumerator. But I think it does not match Ruby's '大クラス主義' (I don't know this word in English), so I suggest to add some methods to Enumerator class. proof of concept attached. Usage: ``` % irb -r irb/completion --simple-prompt >> e=(1..2).step(3) => #<Enumerator: 1..2:step(3)> >> e.receiver => 1..2 >> e.method_name => :step >> e.arguments => [3] ``` `#method` is conflict with `Kernel#method`, so use `#method_name` instead. ---Files-------------------------------- poc.diff (1.42 KB) -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>