ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: shevegen@gmail.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:95237] [Ruby master Feature#16241] Shorter syntax for anonymous refinements
Date: Sat, 05 Oct 2019 22:40:38 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-81910.20191005224038.326f4d21a2269a39@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-16241.20191005190403@ruby-lang.org

Issue #16241 has been updated by shevegen (Robert A. Heiler).


Hmm. I think there was another suggestion some months ago that also suggested
simplifications or "beautification" in regards to refinements.

In general I like ideas that try to make the refinement feature more accessible.

Syntax has been the major reason why I have not been using refinements in my own
code; oddly enough, I 100% agree that it is a good idea to have refinements, but
the syntax always felt ... clunky to me. That is mostly my reasoning why I think
simplifications would be nice.

Matz provided a good syntactic "base". For example, to subclass, we do:

   class Foo < Bar

That's very expressive and short.

Refinements on the other hand always felt a bit too verbose to me. That may be 
a personal choice/preference, granted; on the other hand, looking at suggestions
to simplify or beautify it, it does not seem to be a unique opinion as such. :)

(I also have to admit that I once assumed for refinements to work differently,
until I read up on the original proposal. I think a few other ruby users may
have also mis-interpreted how refinements work now and then. I mention this
in particular because I believe matz and the core team would like to have 
clear definitions for any specifications related to refinements.)

I am still not necessarily in big favour of using the word "refining"; it 
also seems not as good as the "Foo < Bar" notation :) - but on the other hand,
this is, I think, still an improvement over the even more (!) verbose variant
that you gave as an example.

By the way, I also completely agree with you here:

> Having shorter syntax could lower the barrier of entry for Rubyist
> wanting to explore this feature

I think simple/expressive syntax can help a LOT.

I think the only complaint I have about "refining" is that the word seems a 
bit strange to me ... I do not have a better name as suggestion, though.

By the way, would we then have two words? E. g. "refine" and "refining"?
Because this may lead to confusion; may be better to settle just on one
either way. (Or perhaps, if that requires modifications and deprecations,
to aim for ruby 4.0 with that, but with simplification as the primary
goal.)

zverok wrote:

> As I've written elsewhere in this tracker, the most useful case for
> refinements is "in current module, I want some shortcuts for my
> code to look cleaner". 

Yup, I agree.

> So, "inplace refinements" is probably the main kind of refinements
> the developer could care; while "refinements in a module"

I think we have to be careful here to not make refinements more complicated
or complex, or add more than one refinements in place. This is, I think,
what is good about the proposal here in principle, since the primary (or
sole) aim appears to be to lead to a lighter syntax, which I think would
be good, even if the semantics remain the same in regards to refinements.

If possible, anyone able to come up with other names or syntax could 
add a comment or two in regards to the word "refining". I personally have
not fully made up my mind yet; I am not in favour or disfavour of the
word per se. I think the only statement I can make is that it seems to
be better than the older/current variant. But perhaps I am overlooking
something; may need someone who has used refinements in the past (I
can not remember that other issue where someone has suggested a 
simplification syntax-wise some months ago ...)

----------------------------------------
Feature #16241: Shorter syntax for anonymous refinements
https://bugs.ruby-lang.org/issues/16241#change-81910

* Author: palkan (Vladimir Dementyev)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
The original discussion is here https://bugs.ruby-lang.org/issues/14344.

tl;dr
- Refinements are often used in-place with anonymous modules
- Having shorter syntax could lower the barrier of entry for Rubyist wanting to explore this feature
- Previous syntax suggestions were not accepted.


I suggest adding a shorter syntax (technically, API):

```ruby
# before
using(Module.new do
  refine Array do
    def foo;"bar";end
  end
end)

# after
refining Array do
  def foo; "bar"; end
end
```

The original idea was to use `using_refined` instead of `refining` but after discussing with Matz we decided that it's too verbose, and `refining` seems better. But is it good enough? Any thoughts?




-- 
https://bugs.ruby-lang.org/

      parent reply	other threads:[~2019-10-05 22:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <redmine.issue-16241.20191005190403@ruby-lang.org>
2019-10-05 19:04 ` [ruby-core:95234] [Ruby master Feature#16241] Shorter syntax for anonymous refinements dementiev.vm
2019-10-05 22:05 ` [ruby-core:95236] " zverok.offline
2019-10-05 22:40 ` shevegen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-81910.20191005224038.326f4d21a2269a39@ruby-lang.org \
    --to=ruby-core@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).