[#83096] File.setuid? on IO (Re: [ruby-cvs:67289] normal:r60108 (trunk): file.c: release GVL in File.{setuid?, setgid?, sticky?}) — Nobuyoshi Nakada <nobu@...>
On 2017/10/04 8:47, normal@ruby-lang.org wrote:
5 messages
2017/10/04
[#83100] Re: File.setuid? on IO (Re: [ruby-cvs:67289] normal:r60108 (trunk): file.c: release GVL in File.{setuid?, setgid?, sticky?})
— Eric Wong <normalperson@...>
2017/10/04
Nobuyoshi Nakada <nobu@ruby-lang.org> wrote:
[#83105] Re: File.setuid? on IO (Re: [ruby-cvs:67289] normal:r60108 (trunk): file.c: release GVL in File.{setuid?, setgid?, sticky?})
— Nobuyoshi Nakada <nobu@...>
2017/10/04
On 2017/10/04 15:55, Eric Wong wrote:
[#83107] Alias Enumerable#include? to Enumerable#includes? — Alberto Almagro <albertoalmagro@...>
Hello,
9 messages
2017/10/04
[#83113] Re: Alias Enumerable#include? to Enumerable#includes?
— "Urabe, Shyouhei" <shyouhei@...>
2017/10/05
This has been requested countless times, then rejected each and every time.
[#83129] Re: Alias Enumerable#include? to Enumerable#includes?
— Alberto Almagro <albertoalmagro@...>
2017/10/05
Sorry I didn't found it on the core mail list's archive.
[#83138] Re: Alias Enumerable#include? to Enumerable#includes?
— "Urabe, Shyouhei" <shyouhei@...>
2017/10/06
Ruby has not been made of popular votes so far. You have to show us
[#83149] Re: Alias Enumerable#include? to Enumerable#includes?
— Eric Wong <normalperson@...>
2017/10/06
Alberto Almagro <albertoalmagro@gmail.com> wrote:
[#83200] [Ruby trunk Feature#13996] [PATCH] file.c: apply2files releases GVL — normalperson@...
Issue #13996 has been reported by normalperson (Eric Wong).
4 messages
2017/10/10
[ruby-core:83571] [Ruby trunk Feature#14056] Add Module#deprecate_public for deprecation of public methods
From:
ruby-core@...
Date:
2017-10-26 05:53:34 UTC
List:
ruby-core #83571
Issue #14056 has been updated by marcandre (Marc-Andre Lafortune).
Assignee set to matz (Yukihiro Matsumoto)
Just curious about the use case: since you have the control over private methods, why not simply do something like
~~~ ruby
class MyClass
def meth
warn "meth is deprecated, please call instead some_other_meth"
_meth
end
private
def _meth
1
end
end
~~~
Internally, you use `_meth` until the next major release. The, you're free to delete `meth` and rename usage of `_meth` to `meth` in your code.
Also, FWIW I think of two ways to achieve your feature without modifying the VM.
One way would be to check `caller_locations.first.path`. Another way is by using `method_missing` and `respond_to_missing?`.
A third way would be using the gem `binding_of_caller` and check who the caller is, but that's not portable though.
Nevertheless, I'm not opposed to the feature, I'm just not convinced of it's necessity. I would much prefer having something like `binding_of_caller` become part of the language.
----------------------------------------
Feature #14056: Add Module#deprecate_public for deprecation of public methods
https://bugs.ruby-lang.org/issues/14056#change-67598
* Author: jeremyevans0 (Jeremy Evans)
* Status: Open
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version:
----------------------------------------
The attached patch allows you to make a method private, but have
calling it publicly (either directly or via public_send) emit a
warning instead of raising a NoMethodError.
This is mostly useful in library development, where you want to
continue using a method internally, and you want to disallow external
use, but you want existing external users who are using the method to
receive a warning during a deprecation period instead of breaking their
code immediately.
I believe this feature is not possible without modifying the VM
(as the patch does). You can emit a deprecation message inside the
method, but I don't believe you can make it conditional on whether the
method was called publicly or privately, as that information isn't exposed.
Use is similar to public/protected/private when called with arguments:
~~~ruby
class MyClass
def meth
1
end
deprecate_public :meth
end
MyClass.new.meth
# warning: calling private method meth on #<MyClass:0x00001c896dfb1a90> \
# via deprecated public interface
# => 1
~~~
Module#deprecate_public makes the method private, but sets a flag on
the method entry that it is deprecated, and if calling the method would
usually raise a NoMethodError due to visibility, instead a warning is
printed and then method call works as if it were declared public.
There are some issues with this implementation of deprecate_public:
1) It doesn't handle scope visibility, so the following
does not work like public/protected/private:
~~~ruby
class MyClass
deprecate_public
def meth
1
end
end
~~~
Currently, this deprecate_public call would do nothing
as no arguments were given. It's probably possible to
handle scope visibility as well, but it would require
additional internal changes.
2) It is rather inefficient, as it first exports the method
in the module as public and then private, before setting
the deprecation flag. However, this method is not likely
to be a bottleneck in any reasonable code. It was done this
way to reuse the most existing code and still ensure that
methods will be setup in the class itself and that method
caches will be cleared appropriately.
3) When public_send is used, this does not print the receiver
of the public_send method, instead it prints the module
that used the deprecate_public call. I'm not sure whether
the calling information is available from rb_method_call_status,
or how to access it if it is available.
4) This doesn't currently handle protected methods, but I
think changing it to do so isn't too difficult.
5) The method name isn't great, hopefully someone can think of
a better one that isn't much longer.
---Files--------------------------------
0001-Add-Module-deprecate_public-for-deprecation-of-publi.patch (11.1 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>