Yukihiro Matsumoto wrote:
> Hello,
>
> In message "Re: Private visibility should be removed from Ruby 2 [was: Caveats with #method_missing]"
>     on Mon, 2 Oct 2006 13:21:27 +0900, "Tomasz Wegrzanowski" <tomasz.wegrzanowski / gmail.com> writes:
>
> |Having a single well-defined interface was a big win for Smalltalk.
> |Ruby is almost there, but not quite. What is the reason for Ruby
> |to have "almost-Smalltalk" object model ?
>
> Because Ruby is not Smalltalk.  Really.
>
> Let me elaborate a bit.  Since I made the syntax of Ruby more
> traditional than Smalltalk's "everything is a message passing" style,
> you can write traditional code in Ruby, for example:
>
>   print "hello world\n"
>
> rather than
>
>   "hello world" printIt.
>
> or something like that.  If everything procedure is a method, what
> should I do?  There were several choices, and I chose "print" to be a
> method with implicit receiver, but made it "private" to detect weird
>
>   "foobar".print "hello world\n"
>
> as an error.  If you want to remove "private" from Ruby2, I expect
> your proposal addresses the above issue.

With the proposal of #funcall, I think a lot of people were confounded.
What did fucntions have to do with private vs. public. But it becomes
increasing clear what matz has done, for better of worse. He noticed a
function is a  method without a receiver, which by all accounts is
essentially the same as a method that can take no other reciever but
self. In turn, that fits the concpet of a so-called "private" method.
It's a very interesting sort of conscilence. Unfortuately the mixed
terminolgy can be quite confusing since the two aren't readily
associated. How many Rubyists would know that saying "private function"
is redundant?

Honestly one the syntax features that UI alwasy found out of place was
'private' keyword. Here was essentially a DECLARATION in a language
that sought to avoid declarations. I always felt at the least it would
be better to make it take a block, 'private do ... end'. And I see that
could just as well be 'function do ... end'. But why not address each
function definition?

  defunc foo
    ...
  end

I'm curious why the public/private nomenclature was chosen over
'method/function' and why#funcall is being suggested now (moving away
from that choice?).

>From a larger perspective, it strikes me that different approaches were
taken for variables as opposed to methods. It is equally possible to
think of instance variables as private attributes. In this case,
un;like methods, it is the private entities that take precedence and
public variables are provided via additional interface methods. The
distiction here is one of syntax made via the @ prefix. Concievably the
same prefix mechism could have been used for private methods.

  def @foo
    ...
  end

T.