Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support method call without parens? #84

Closed
st0012 opened this issue May 13, 2017 · 6 comments
Closed

Support method call without parens? #84

st0012 opened this issue May 13, 2017 · 6 comments

Comments

@st0012
Copy link
Member

st0012 commented May 13, 2017

Currently any method call in goby needs parens to wrap parameters like foo(1), this is not a big issue in normal cases. However, in convention some method calls like include, require in Ruby don't need to wrap params with parentheses, we treat them as a configuration more than a method call.

require "foo" #=> This is actually require("foo")

class Bar
  include Foo #=> This is actually include(Foo)
end

So I need some feedback about if goby should support this kind of syntax or we should always use parens. 🙏

@adlerhsieh
Copy link
Member

Personally I think it is necessary. If we want to invite more users from Ruby (which I believe is one main feature of this language) to use Goby then they would expect this feature.

However there are still several good reasons if we don't want to support it. For example, improving performance for the parser by only handling parentheses.

@st0012
Copy link
Member Author

st0012 commented May 13, 2017

@adlerhsieh I don't think we can gain much performance improvement by dropping this feature since the current performance bottleneck is VM.
In my opinion, the main reason for not supporting this besides technical difficulty is code consistency. In Ruby you can write most of things in many different ways, and that can cause some confusion so we need style guide(s) to tell programmers write code consistently. But in some programming languages like go, the syntax is very limited which in sometimes is very verbose, but this also makes program more easy to understand and maintain.

@adlerhsieh
Copy link
Member

Yeah that makes sense. I'm fine with both, then. You can make the call.

@st0012
Copy link
Member Author

st0012 commented May 14, 2017

@adlerhsieh I think I won't support it for now and announce this decision is readme with this PR. If people really want this to be supported we can reconsider it.

@adlerhsieh
Copy link
Member

Do you want to close this one since this section in README is added?

@st0012
Copy link
Member Author

st0012 commented May 16, 2017

Sure

@st0012 st0012 closed this as completed May 16, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants