Little Things

[Trans]

Rob S. wrote:

How is this better then having send and the __send alias, along with
the corresponding bang methods? It seems to me having one method that
means “send a message”, and then having one version be the “dangerous”
version is much more obvious then having object_send and
instance_send.

I just explained that. I’m sorry but I don’t understand how is is not
clear. I guess all I can do is try to sum up on a bullet point basis:

1. you have 4 methods when only 2 are needed

2. and two of those methods are ugly shadow methods

3. #send is common enough a word as to be too easily over-ridden

4. using #__send to circumvent this makes #send completely pointless

If a ruby newbie tried “send” and saw it fail due to a private method,
I bet once they saw “send!” in the docs or in irb they would
immediately know how it works. Its aligns perfectly with many other
things in the std lib, and fits perfectly with POLS.

not really since 90+% of the time “!” means in place change. personally
i could care less about the !, to me that’s not really the point –
there’s a more fundamental issue here. To me POLS is

1. methods starting with ‘object_’ or ‘instance_’ are Vital methods and
   should not be overridden (unless you know exactly what the heck it is
   you’re doing)

2. methods starting with ‘instance_’ provide Internal access to the
   receiver.

As for protecting from people overriding it, I think having the
underscore forms is enough. YSYEO (“You’ll shoot your eye out.”) I’m
sure there are programs were object_id and other meta-methods are
overridden. All you can do is warn people against doing it, test your
code, and of course choose libraries that behave well.

There was a reason #id was changed to #object_id.

T.

[Trans]

On 1/4/07, [email protected] [email protected] wrote:

On Thu, 4 Jan 2007, matt wrote:

So everyone be careful not to add your +1 if it’s already there

What is the meaning of “+1” and “+” ? This list seems to use it
extensively

It basically means “I agree”, or “Add me to the list of people who
support this.”

And is likely from the system of voting via wiki page, where you edit
the page and add one to the number following the option you support

martin

[Trans]

Hi –

On Thu, 4 Jan 2007, [email protected] wrote:

sure there are programs were object_id and other meta-methods are
overridden. All you can do is warn people against doing it, test your
code, and of course choose libraries that behave well.

alternatively, it can be externalized so no matter how hard you muck about
with objects you cannot break certain unalienable behvaiours we desire them
to
have.

Do you really think no one will ever do:

def Pervasives.send
# …
end

?

David

[Trans]

Hi –

On Thu, 4 Jan 2007, Rob S. wrote:

If a ruby newbie tried “send” and saw it fail due to a private method,
I bet once they saw “send!” in the docs or in irb they would
immediately know how it works. Its aligns perfectly with many other
things in the std lib, and fits perfectly with POLS.

I’ll add that if a nuby tries “send”, said nuby had better realize
that it is using a fairly powerful technique and would be well advised
to educate itself fully about it.

David

[Trans]

Trans wrote:

Another option is to make __id, __send, and __send! impervious to
metaprogramming. Say, they are listed in #methods because that’s useful
for irb-learning, but remove_method and the like are no-ops when called
on __id, __send, and __send!.

Again, there would be no point in having #object_id, #send and #send!
in that case.
Agreed.

If given a choice between a method that works and one
that might work, which one would you choose?
The simple one. Here, __* are all unlikely to be overridden (and well,
can’t - Ruby should stop you from overriding them). __ is a flag that
this is a special thing that can’t be overridden. It’s ridiculously
ugly, as a sign that it should be used sparingly, both by the language
designers and by users. Finally, the names are short, for when you are
writing metacode.

My point was that we need not extract the cool methods into Pervasives
in order to achieve metaprogramming simplicity.

(On a side note: How do you find the true class of a BlankSlate?)

Devin

[Trans]

2007/1/1, Yukihiro M. [email protected]:

It’s not really a meta class since it’s not only for classes,
nor virtual_class since it’s not virtual anymore.

In my mindset, two candidates have survived. singleton_class (or
singletonclass), which can easily be confused with a class in the
singleton design pattern. And eigenclass, which is unfamiliar for
most people.

                                                    matz.

I’m all for eigenclass. Let’s have some personnality and impose our own
concepts. And by using an uncommon term like this one, we have the
advantage
to be able to define it like we want in the computer domain.

[Trans]

Trans wrote:

I was a bit surprised about Matz mention of the little things in his
last ketynote.
Little things can make all the difference! In fact, long time Rubyists
have been waiting a long for some important “little” things. Here’s
some of the things on my little list…

First off great discussion and thank you kindly for posting the link!
Ironically, your first point about the discussion of the little things
vs Mat’z “the need for speed” has mostly gone untouched. I believe Matz
has brought up some excellent points in that slide show and that was the
first time I noticed his sense of urgency in getting the ball rolling on
1.9.

I should note before continuiing that I know nothing of the progress of
1.9 and haven’t contributed in any way but like most am anxiously
looking forward to it!

My belief from reading that slide show is that the core team must be
getting hounded with suggestions, observations, complaints, etc… and
this is causing some considerable lag and frustration in it’s life cycle
and this is a cry by the lead saying “Enough is enough!” I think he is
absolutely right, his team needs to push this thing out and then
formalize the process of change. IMO, they are pretty much forced to
accept a formalized process for change requests as there is now a lot of
momentum behind the language. I believe this is a key milestone for
Ruby hitting the big time.

I also really like his definition of Ruby as an “Agile” language! This
is a perfect definition and it seems so obvious after his statement.

As for the concerns over documentation, I believe it’s need is too much
hyped about. Ruby is very intuitive by design and due to IRB and
metaprogramming, most of what one needs can be retreived quite easily
after reading a book or 2 and by coming here as I often do

He is not saying that we should stop talking about the little things,
but that we must concentrate on the big things in order that we keep up
and have a platform in which to add the little things later. A possible
analogy is a story I heard a few years back.

A professor placed a container on his desk and then proceeded to put
rocks into it, he continually placed smaller and smaller rocks into the
container as space would allow and then finally filled the remaining
space with sand. He then asked what the class learned from this
experiment.

One student exclaimed that the experiment simply showed that we can
always strive to fit more in.

The professor corrected the student and explained that if we don’t do
the big things first, they will never be completed after perfoming all
the small things.

ilan

[Trans]

On Thu, 4 Jan 2007, Devin M. wrote:

order to achieve metaprogramming simplicity.

(On a side note: How do you find the true class of a BlankSlate?)

Pervasives.class obj

-a

[Trans]

On Thu, 4 Jan 2007 [email protected] wrote:

agreed.
have.

Do you really think no one will ever do:

def Pervasives.send

…

end

?

yes. the Pervasives module would be designed at the C level to prevent
modification, if you read my initial post you’ll see that’s it’s entire
purpose:

harp:~ > cat a.rb
class Pervasives
freeze
class << self
freeze
end
end

class Pervasives
def self.send
end
end

harp:~ > ruby a.rb
a.rb:9: can’t modify frozen object (TypeError)

i know this can be subverted, but it can be done at the C level.

the point is to have a single object responsible for maintaining and
retrieving
certain unalterable traits of objects. this can either be done somehow
for
every object or for one object. i prefer the one object approach
because it
streamlines the api: you don’t have to remember send! vs. send or
object_eval
vs instance_eval, you use the Pervasives handle with the normal method
to cut
straight to the heart of of any object.

regards.

-a

[Trans]

Devin M. wrote:

My point was that we need not extract the cool methods into Pervasives
in order to achieve metaprogramming simplicity.

Yes, you’re right. It’s not neccessary. But it’s also not
metaprogramming with guaranteed behavior. I tend to lean toward the
guaranteed bahavior myself. But the other is okay IF the methods stay
out or our way --but that doesn’t mean they have to be ugly and it
certainly doesn’t mean we should think we have solved the problem by
adding an extra ugly alias.

(On a side note: How do you find the true class of a BlankSlate?)

In my version I added an intermediary. Eg.

blankslate.self.class

(though I’ve never been sure what the best name for it is)

T.

[Trans]

On 1/4/07, [email protected] [email protected] wrote:

My point was that we need not extract the cool methods into Pervasives in
order to achieve metaprogramming simplicity.

(On a side note: How do you find the true class of a BlankSlate?)

Pervasives.class obj

-a

Interesting. I found this sort of odd though:

Pervasives.class Pervasives

Not really a bad thing since it is rather contained, but still a little
odd.

One idea is to provide a module like Pervasives that is mixed in
rather than external. Object could then make use of those directly and
you could then do this:

class Object
inlude Pervasives # really done in the ruby C code during setup.
undef_meth :send
end

Pervasives.instance_method(:send).bind(obj).call(:my_message)

Of course a little help from the module might be nice as well:

Better name?

Pervasives.deliver obj, :send, :my_message

Of course, the second one isn’t too far off from the original idea but
this does allow both a standard mixin approach and a functional
approach to be used.

Brian.

[Trans]

Hi –

On Sat, 6 Jan 2007, Ilan B. wrote:

My belief from reading that slide show is that the core team must be
getting hounded with suggestions, observations, complaints, etc… and
this is causing some considerable lag and frustration in it’s life cycle
and this is a cry by the lead saying “Enough is enough!” I think he is
absolutely right, his team needs to push this thing out and then
formalize the process of change. IMO, they are pretty much forced to
accept a formalized process for change requests as there is now a lot of
momentum behind the language. I believe this is a key milestone for
Ruby hitting the big time.

Actually there’s been a formalized process for several years:
http://www.rcrchive.net. It’s recently been re-started, and there are
some differences in logistics (mailing lists instead of comments on
the site; more group participation in revision of RCR text). But the
basic components of the RCR, and the presence of a process, are not
new.

David

[Trans]

Regarding ‘funcall’, I would rather support a ‘send’-derived word which
reflects the message-passing nature of what is really going on. Also, my
brain reads ‘funcall’ most intuitively as ‘FUNCtion ALL’. However I
think the tradition of ! modifying the receiver makes ‘send!’ for
private methods not good. I don’t have a better suggestion, though.

Regarding overriding ‘send’, I don’t think that any method is too
important to be overridden. Perhaps ‘__send’ to always call the original
version would be ok, but the idea of permanently disallowing some
operation because it’s “important” doesn’t sit well with me. If I want
to break Ruby, I want it to graciously break, instead of saying ‘No’.

Regarding the name of singleton classes, I think ‘eigenclass’ is ok. I
am partial to ‘shadow_class’, because the singleton class shadows the
real class. I would like to be allowed to instantiate new objects from
them, as a sort of backhanded prototyping.

Evan W.

[Trans]

Hi –

On Mon, 8 Jan 2007, Evan W. wrote:

Regarding ‘funcall’, I would rather support a ‘send’-derived word which
reflects the message-passing nature of what is really going on. Also, my
brain reads ‘funcall’ most intuitively as ‘FUNCtion ALL’. However I
think the tradition of ! modifying the receiver makes ‘send!’ for
private methods not good. I don’t have a better suggestion, though.

! doesn’t mean modifying the receiver, though. It means “dangerous”.
It’s used often for modifying receivers, but that’s never been what
Matz says it means; that’s just one form of danger.

Regarding overriding ‘send’, I don’t think that any method is too
important to be overridden. Perhaps ‘__send’ to always call the original
version would be ok, but the idea of permanently disallowing some
operation because it’s “important” doesn’t sit well with me. If I want
to break Ruby, I want it to graciously break, instead of saying ‘No’.

Regarding the name of singleton classes, I think ‘eigenclass’ is ok. I
am partial to ‘shadow_class’, because the singleton class shadows the
real class. I would like to be allowed to instantiate new objects from
them, as a sort of backhanded prototyping.

You can do something along these lines by cloning objects:

irb(main):003:0> a = Object.new
=> #Object:0xb7f34c8c
irb(main):004:0> def a.x; puts “hi”; end
=> nil
irb(main):005:0> b = a.clone
=> #Object:0xb7f22ba4
irb(main):006:0> b.x
hi

David

[Trans]

[email protected] wrote:

that it is using a fairly powerful technique and would be well advised
to educate itself fully about it.

True for “instance sending” (eg funcall/send!/etc.), but is #send
really all that? Isn’t it just a dynamic dot? If what you say is true
then why not:

obj.call! message

and

obj.fcall! message

And extrapolating over the whole board of Ara’s Pervasives:

id!
class!
methods!
…etc…

“!” means powerful!

T.

[Trans]

On Jan 8, 2007, at 6:43 AM, [email protected] wrote:

think the tradition of ! modifying the receiver makes ‘send!’ for
private methods not good. I don’t have a better suggestion, though.

! doesn’t mean modifying the receiver, though. It means “dangerous”.
It’s used often for modifying receivers, but that’s never been what
Matz says it means; that’s just one form of danger.

For example, exit!() does not modify a receiver.

James Edward G. II

[Trans]

Re David: But I don’t want to copy the data, just the behavior.

Re James: You’re right. If I’ve gotten used to those, I can get used to
‘send!’.

Evan W.

[Trans]

Mauricio has already implemented (sort of) what I want regarding .new. I
didn’t realize that this sort of worked in 1.8.2, except for the
inheritance persistence (which is important to me). Was it removed as a
side-effect of some other optimization?

http://eigenclass.org/hiki.rb?cmd=view&p=prototype-based+OOP

Evan W.

[Trans]

On Thu, 4 Jan 2007, Trans wrote:

certainly doesn’t mean we should think we have solved the problem by
adding an extra ugly alias.

(On a side note: How do you find the true class of a BlankSlate?)

In my version I added an intermediary. Eg.

blankslate.self.class

(though I’ve never been sure what the best name for it is)

i think you guys underestimate the difficulties requiring certain
methods
imposes. let’s just say you wrote, oh, an xml generator using ruby’s
cool
method_missing feature. now, you cannot easily have any xml tags that
look
like this

xml.ancestors{ ‘oops’ }
xml.class{ ‘oops’ }
xml.display{ ‘oops’ }
xml.extend{ ‘oops’ }
xml.freeze{ ‘oops’ }
xml.id{ ‘oops’ }
xml.method{ ‘oops’ }
xml.new{ ‘oops’ }
xml.send{ ‘oops’ }
xml.taint{ ‘oops’ }
xml.type{ ‘oops’ }

not to mention you cannot have tags with dashes or other weird chars in
them… but that’s a separate design flaw with sort of thing.

my point, is that send/send! is only the tip of the iceburg of name
clashes
one runs into when doing any serious metaprogramming/dsl work with ruby.
it’s
one of the bugs people on this list simply ignore but production coders
cannot: “you mean our food products list cannot use the tag ‘freeze’!?”

i have to ask anyone who does think this is true to point out their
libraries
which make use of either metaprogramming or dsls because i’m positive
that any
such libs, including my own, suffer from these kinds un-fixable flaws.

i really think people are not seeing the forest for the trees. the
issue with
send/send! is not the name: it’s that the concept of both needing
certain
methods to work a certain way and allowing, even encouraging via the
popularity of dsl like syntaxes in ruby, that those same methods can be
easily
clobbered sets up a loosey-goosey mess that those of us who require our
code
to run un-attended for months on end get stomach cramps over.

regards.

-a

[Trans]

Hi –

On Thu, 4 Jan 2007, Trans wrote:

and

obj.fcall! message

I’m afraid I don’t follow at all.

And extrapolating over the whole board of Ara’s Pervasives:

id!
class!
methods!
…etc…

“!” means powerful!

It means “dangerous”, and I’m not sure what a dangerous id or class
method would be.

David