From: Robert Dober <robert.dober@...>
Date: 2006-10-04T03:00:47+09:00
Subject: Re: Private visibility should be removed from Ruby 2 [was: Caveats with #method_missing]

------=_Part_72238_27168212.1159898443491
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 10/3/06, Trans <transfire@gmail.com> wrote:
>
>
> 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?


Lots of folks I guess,  if you define a function of a method called without
an explicit receiver.
As a matter of fact I disagree with this definition as there are just no
functions in Ruby.
One might define a "function call" as an implicit method call, for which
there does not seem to be any reason.
There are method calls with an explicit receiver, and there are method call=
s
without.
The later only are allowed for private methods, that is how I found it
defined in Pixcacke, does everyone agree on this?

For what Matz's concern is about avoiding to define #puts etc. on Object
level visibly, I would prefer a different approach.

public and protected modes do not change. private mode changes in so far
that private methods can be called from within the instance of the class of
it's definition, even with an explicit receiver, that can be the Singlteon
class BTW.

#puts and friends are looked after when all other name resolutions fail, a
straight forward idea would be to have a toplevel object of class Void (no
methods) with Kernel mixed in or a specific class TopLevel or BuiltIns. Thi=
s
would have the (ugly?) sideeffect that there would be objects in Ruby that
are not Object.
After some thoughts I believe that this is exactly what Matz wanted to
model, I feel that his original approach was not the best one, because of
all these subtle side effects, that probably were not easily predicatable.


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?).


Me too as I fail to see any needs for functions as long as we accept truely
private methods.
Truely private methods (as right now) are an important modelling tool for
data hiding and I would truely hate to miss this tool in Ruby.

>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


That one I like very much, what would you suggest as call syntax? a.foo or
a.@foo, I simply *hate* the later.

T.
>
>
> Cheers
Robert


--=20
Deux choses sont infinies : l'univers et la b=EAtise humaine ; en ce qui
concerne l'univers, je n'en ai pas acquis la certitude absolue.

- Albert Einstein

------=_Part_72238_27168212.1159898443491--