Project

General

Profile

Actions

Feature #17392

closed

Is there any plan to unify the namespace after ruby3

Added by jackmaple (maple jack) almost 4 years ago. Updated almost 4 years ago.

Status:
Rejected
Assignee:
-
Target version:
-
[ruby-core:101452]

Description

Hello.Currently, methods and variables in ruby are separated (lisp-2 semantics), but few people define variables and methods as the same name, right?
Although some people may do this, should we unify the namespace for the better development of ruby in the future? Does this improve the performance of the language and avoid name confusion.
example:

def foo
    puts "ruby method"
end

foo = 3

puts foo # show 3
foo() # call method

It doesn't feel very good.But can we add an option switch to ensure compatibility?

use ruby3
def foo
    puts "ruby method"
end
foo = 3
puts foo # show 3
foo() # error

If we implement a unified namespace, can we call lambda, proc, block and so on without using call, so that the call forms of methods are unified.

use ruby3
def foo x
    return x + 1
end
f = -> x {x + 1}
foo 2 # result = 3
f 2 # result = 3

In this way, we can make the language more friendly and design more unified.And now there is a scope problem: when defining a method within a method, it should not be visible to the public.

def test
   def test2
       puts "test2"
   end
   puts "test"
end

test # show "test"
test2 # show "test2" but this method should not be called

Although syntax supports defining methods within methods, they should not be visible to the public, so this is also a problem.
What do you think of this problem? Thank you.

Actions #1

Updated by jackmaple (maple jack) almost 4 years ago

  • Description updated (diff)

Updated by chrisseaton (Chris Seaton) almost 4 years ago

but few people define variables and methods as the same name, right?

I don't know - do you? Maybe we should measure it?

should we unify the namespace for the better development of ruby in the future?

I don't know if it's better and does lead to less confusion - does it? Again maybe we should measure it if we wanted to propose it be changed.

Also note that I think Ruby is very deliberately a Lisp-2 - it hasn't become so accidentally.

http://ergoemacs.org/emacs/Matz_Ruby_how_emacs_changed_my_life.html

I don't have links but I think I recall Matz re-asserting that he prefers Lisp-2 more recently than this.

Does this improve the performance of the language

Do you have a specific idea how it could improve the performance of the language?

Updated by matz (Yukihiro Matsumoto) almost 4 years ago

  • Status changed from Open to Rejected

I disagree with the proposal for a few reasons:

  • It would introduce a huge compatibility breakage. We cannot accept that.
  • I believe Lisp-2 behavior is more natural for OOP (not much for FP, I admit)
  • It wouldn't improve performance. Naive implementation requires 2 steps (retrieve a method and call) instead of 1 in Lisp-2 (just call).

Matz.

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0