From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <e@80x24.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-ASN:  
X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00
	shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0
Received: from localhost (dcvr.yhbt.net [127.0.0.1])
	by dcvr.yhbt.net (Postfix) with ESMTP id 15363201A7;
	Sun, 21 May 2017 04:54:36 +0000 (UTC)
Date: Sun, 21 May 2017 04:54:35 +0000
From: Eric Wong <e@80x24.org>
To: Pat Allan <pat@freelancing-gods.com>
Cc: clogger-public@bogomips.org
Subject: Re: [PATCH] Update respond_to? calls for second argument.
Message-ID: <20170521045435.GA17029@untitled>
References: <D6ACA95E-0296-4CB7-9788-E5CB95291224@freelancing-gods.com>
 <20170521043848.GA25750@starla>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20170521043848.GA25750@starla>
List-Id: <clogger-public@bogomips.org>

Actually, there's also a rb_obj_respond_to API in Ruby 1.9+
which could be used.  It's declared in ruby/intern.h which is a
grey area as far as continued API support goes, and it's not
documented in doc/extension.rdoc, either.

However, there is a rubyspec CAPI test for it; and I'm not sure
the two-arg form of respond_to? is actually used by real Rack
servers.


Sidenote: rb_funcall* functions are always a bit slower since
they need to go through method lookup before dispatch, and can't
benefit from inline method caching, only global method caching.