From: Eric Wong <normalperson@...>
Date: 2017-06-30T08:03:35+00:00
Subject: [ruby-core:81845] Re: [Ruby trunk Feature#13434] better method definition in C API

ko1@atdot.net wrote:
> As I wrote before, I against this idea. My idea is to write
> definitions in Ruby with special form.

Sorry, I wasn't sure what you wanted the last time this came up.
I guess it was around https://bugs.ruby-lang.org/issues/11339
Particularly:
[ruby-core:69990] https://public-inbox.org/ruby-core/55A72930.40305@atdot.net/

I remember not liking Ricsin syntax, but maybe a Ruby API can
be better than Ricsin...

> Comparison:
> 
> * Write info with C
>   * Easy to learn (people should know only C syntax)
>   * Easy to implement
> 
> * Write info with Ruby w/ special firm
>   * Easy to write
>   * Easy to read
>   * Easy to learn (people should know Ruby syntax and some restrictions) (I agree it is possible that "some restrictions" will confuse people.)
>   * We can compile it and know all of information before running Ruby (*1)

OK, I agree.

<snip> excellent explanation.

> Moreover, we can prepare tables.

OK, I like this part.

> Furthermore, we can defer converting until first method call.

<snip> OK that sounds excellent! :)

> ```
> 
> I'm suspect that most of classes are not used (think about many of Exception class) so that this kind of optimization will improve speed (reduce boot time) and memory efficiency.

Yes, that would be great.  However, we will take into account
fork and CoW savings.

Should I try to implement your table idea?  Or did you already
start?  You are more familiar with this, but maybe I can try...


In addition to improved kwarg handling for C methods, my other
goal is to be able to mark read-only/use-once/const/etc. args to
avoid unnecessary allocations at runtime.  This will be more
flexible than current optimizations (opt_aref_with, opt_aset_with, etc).

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>