Forum: Ruby Little Things

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Trans (Guest)
on 2006-12-30 19:28
(Received via mailing list)
I was a bit surprised about Matz mention of the little things in his
last <a
href="http://www.rubyist.net/~matz/slides/rc2006/mgp0001....
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....

* Binding.of_caller. Yes, it's easy to abuse, and should be avoided at
nearly all costs. But there are few pennies worth when nothing else
will do. Some very cool metatricks are made possible by being able to
access the caller's binding --the breakpoint lib being the most well
known.

* <code>object_class</code> instead of </code>class</code>. I get sick
just looking at <code>self.class.foo</code>. And it prevents use of
"class" for other variables/methods. (Hence the all too frequent use of
"klass"). <code>object_class</code> on the other hand is nicely
analogous to <code>object_id</code>.

* Allow a comma between the two <code>alias</code> arguments --getting
an error on that is really annoying. Actually why is <code>alias</code>
a keyword? Why have both <code>#alias_method</code> and
<code>alias</code>? I have always been told that keywords were to be
avoided.

* <code>String#resc</code> as an inversion of
<code>Regexp.escape(string)</code> and <code>String#to_re</code> as an
inversion of <code>Regexp.new(string)</code>.

* I'm dying here from remove_method hacks without
<code>#instance_exec</code>. This has to rank in the top three "little
things" that have been talked about forever, and it isn't that hard to
implement. So what's holding it up?

* A block can't take a block, nor default arguments. What kind of
<code>define_method</code> is this? I realize this a trickier issue.
But at some point the trick has to be performed.

* Close the closures. Writing DSLs is great, but have you noticed they
all share the same closure? Have a way to reset the closure with some
sort of special block notation would shore-up this danger hole. Maybe:

<pre>
  a = 1
  dosomething do! |x|
    p a  #=> error
  end
</pre>

* Another hassle when metaprogramming. <code>#send</code> should work
for public methods only! There's a big issue with backward
compatibility here. I have the solution: <code>#object_send</code>.
It's a better name anyway b/c it stays out of the way (eg. my Email
module would like to have a #send method, you dig?). And #send itself
could be deprecated slowly. BTW <code>#funcall</code> for the alternate
private-accessing send is a <b>terrible</b> name, try
<code>#instance_send</code>. (And yes, I'm begging here!)

* This one's more of my own pet-peeve but nontheless, who wouldn't want
a nice word alias for Class#===. In most cases I prefer to read what
I'm doing rather then recall the interpretation of a symbol. There are
of course some symbols that are rather obvious, either by indication of
their form (eg. <<) or by their widespread use (eg. =), but Class#===
is not one of them. I would much prefer to see:

  <pre>
    MyClass.instance?(myobject)
  </pre>

But I'm not picky about what word to use as long as it's readable.

* Oh, and lets not forget the forever arguable method name for (class
<< self; self; end). But please give us something concise.

No doubt there other little things left unmentioned, and obviously some
are more important than others. But in any case, it's clearly striking
that after hearing for so long about many such well-accepted "little
things", that Ruby has yet to take them in. I have a silly theory about
this actually --as odd as it may seem. The 1.9 version is the last on
the chain before 2.0 b/c matz is against using double-digit minor
numbers, eg 1.10. So we're is stuck with 1.9 as his test bed for 2.0.
Since 1.8 can only increment by teeny, these "little things", being not
little enough, can't make it in. Hence Ruby is being held back by a
version number policy!!! I think Matz just needs to get on with it (hey
look forward to 3.0!) or just lossen the version policy constraints.

T.

PS. [And, yes, I took my own advice. I removed this from my blog --"it
is better to share than to own".]
matt (Guest)
on 2006-12-30 20:08
(Received via mailing list)
Thanks for bringing these slides to my attention.  This one caught my
eye:
http://www.rubyist.net/~matz/slides/rc2006/mgp00027.html

"We need to Document Ruby (if Possible)." as part of the Design Game of
improving Ruby.

That kind of a statement is what could potentially kill the language.
We can have the best language on the Planet, but if the language
features are only accessible to those that are willing to go code-diving
for the answers, then the target audience is going to be slim.

The truth is that there are a lot of well intentioned programmers out
there, but they don't have the first clue (or inclination) to go digging
deep into the bowels of Ruby (or any language).

That is why some of the less elegant languages have succeeded, and have
such a large following.  It is (in large part) because of there
documentation. It is up-to-date, adequate, easy to search, and
well-defined.

I don't pretend that all share my view on documentation, but for the
Ruby leader/CEO to put documentation so far down on the list I think is
going to make it difficult for language to grab ahold of programming
share the way that Perl, Python and PHP have.

my .02

Matt
Trans (Guest)
on 2006-12-30 21:44
(Received via mailing list)
matt wrote:
> Thanks for bringing these slides to my attention.

Your welcome. I'm glad something good came from this post at least.

Sorry about the html btw, should have removed that.

> for the answers, then the target audience is going to be slim.
> I don't pretend that all share my view on documentation, but for the
> Ruby leader/CEO to put documentation so far down on the list I think is
> going to make it difficult for language to grab ahold of programming
> share the way that Perl, Python and PHP have.

Yea, I didn;t notice taht before. that is an odd statment to make. But
I wouldn't put too much emphisis on it --sometimes people say things
without meaning all the conotations tha can go with them.

T.
M. Edward (Ed) Borasky (Guest)
on 2006-12-30 22:33
(Received via mailing list)
Trans wrote:
>> for the answers, then the target audience is going to be slim.
>> I don't pretend that all share my view on documentation, but for the
>> Ruby leader/CEO to put documentation so far down on the list I think is
>> going to make it difficult for language to grab ahold of programming
>> share the way that Perl, Python and PHP have.
>>
>
> Yea, I didn;t notice taht before. that is an odd statment to make. But
> I wouldn't put too much emphisis on it --sometimes people say things
> without meaning all the conotations tha can go with them.
Yes ... I was there, and in fact a group formed to do just that --
document the syntax and semantics of Ruby 1.8. I know there's a web
site, but I've forgotten where it is. Quite a few other "Ruby
improvement" projects started up at RubyConf 2006, and for the most part
they seem to be progressing nicely.

However, regarding "programming share", or, as Eric Raymond says, "World
Domination"
(http://www.catb.org/~esr/writings/world-domination...),
I don't think programming share is as simple as having better
documentation than Perl, Python or PHP. Programming share comes from
"industrial support", as demonstrated by Sun, IBM and Microsoft.

Perl and Python, and even PHP, to some extent, are very much "rebel
languages" alongside Java and C++. Should Ruby aim for programming share
within the rebel languages group? Sure, why not? Yes, Ruby should be as
well documented as the other three. But is achieving programming share
relative to Java or C++ as an "industrial strength general purpose
object oriented language" a realistic, achievable goal?

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.
Devin M. (Guest)
on 2006-12-30 22:53
(Received via mailing list)
I wonder if the reason a lot of these things don't happen is that matz
doesn't really need them, and those that do, can't agree on a syntax (or
elect a representative to make the decision for them). See below.

Trans wrote:
> * Binding.of_caller.
I'd really prefer something more flexible, like what Mauricio did, or
what Evan is doing with Rubinius.

> * <code>object_class</code> instead of </code>class</code>.
Interesting thought, but two things:
- We could just fix it so you can say "class = ...". After all, local
variable "foo" and method call "self.foo" can coexist.
- It breaks the Huffman principle (for that matter, so does the current
notation) that Tanaka A. cited at RubyConf '04. We use self.class a
heck of a lot more than object_id -- why should its name be longer?

> * Allow a comma between the two <code>alias</code> arguments
I think the reason both alias and alias_method exist is because the
latter's supposed to be limited to dynamic situations. Akin to def vs
define_method, undef vs undef_method, etc. That said, I'm ambivalent.

> * A block can't take a block, nor default arguments. What kind of
> <code>define_method</code> is this? I realize this a trickier issue.
See 1.9.

> * Close the closures.
Interesting. Of course, the method author has the choice of calling
instance_eval. And, well,

def do!(&blk)
   obj = Object.new
   obj.define_method(:my_little_pony, &blk)
   obj.method(:my_little_pony) #.to_proc, if you prefer
end

a = 1
dosomething &do! {|x|
   p a
}

> * Another hassle when metaprogramming. <code>#send</code> should work
> for public methods only!
See 1.9.

> * This one's more of my own pet-peeve but nontheless, who wouldn't want
> a nice word alias for Class#===.
I'd like a nice word alias for Object#===. With Class#===, I prefer
using is_a? class.

Oh, and the spirit of Dave T. asks you to PDI.

Devin
Devin M. (Guest)
on 2006-12-30 23:03
(Received via mailing list)
Duh... ignore this part. :P
Trans (Guest)
on 2006-12-30 23:55
(Received via mailing list)
Devin M. wrote:
> I wonder if the reason a lot of these things don't happen is that matz
> doesn't really need them, and those that do, can't agree on a syntax (or
> elect a representative to make the decision for them). See below.

Well, it be nice to know what matz thought.

> Trans wrote:
> > * Binding.of_caller.
> I'd really prefer something more flexible, like what Mauricio did, or
> what Evan is doing with Rubinius.

You mean a frame stack?

> > * <code>object_class</code> instead of </code>class</code>.
> Interesting thought, but two things:
> - We could just fix it so you can say "class = ...". After all, local
> variable "foo" and method call "self.foo" can coexist.

Can it be done? Although, you loose access to the class in that case.
I'd rather have both.

> - It breaks the Huffman principle (for that matter, so does the current
> notation) that Tanaka A. cited at RubyConf '04. We use self.class a
> heck of a lot more than object_id -- why should its name be longer?

But at the same time promotes duck typing ;-)

> > * Allow a comma between the two <code>alias</code> arguments
> I think the reason both alias and alias_method exist is because the
> latter's supposed to be limited to dynamic situations. Akin to def vs
> define_method, undef vs undef_method, etc. That said, I'm ambivalent.

> See 1.9.

Sure I know. But that's like how many years away?

> > * This one's more of my own pet-peeve but nontheless, who wouldn't want
> > a nice word alias for Class#===.
> I'd like a nice word alias for Object#===. With Class#===, I prefer
> using is_a? class.

However, it's safer to ask the class since the object can more readily
"lie".

> Oh, and the spirit of Dave T. asks you to PDI.

That's almost funny :D

Anyone else have any other common little things to add?

T.
Daniel S. (Guest)
on 2006-12-31 00:49
(Received via mailing list)
I mostly agree, with some of the additions of course being more
important than others.

On Sun, 2006-12-31 at 02:27 +0900, Trans wrote:
> * <code>object_class</code> instead of </code>class</code>. I get sick
> just looking at <code>self.class.foo</code>. And it prevents use of
> "class" for other variables/methods. (Hence the all too frequent use of
> "klass"). <code>object_class</code> on the other hand is nicely
> analogous to <code>object_id</code>.

I completely agree here.

> * Allow a comma between the two <code>alias</code> arguments --getting
> an error on that is really annoying. Actually why is <code>alias</code>
> a keyword? Why have both <code>#alias_method</code> and
> <code>alias</code>? I have always been told that keywords were to be
> avoided.

I would personally prefer that the `alias' keyword be removed, but I
have noticed how at least one prominent Rubyist, which has my utter
respect, tends to use it all the time. Nonetheless, be gone with it!

> * A block can't take a block, nor default arguments. What kind of
> <code>define_method</code> is this? I realize this a trickier issue.
> But at some point the trick has to be performed.

+1

> * Another hassle when metaprogramming. <code>#send</code> should work
> for public methods only! There's a big issue with backward
> compatibility here. I have the solution: <code>#object_send</code>.
> It's a better name anyway b/c it stays out of the way (eg. my Email
> module would like to have a #send method, you dig?). And #send itself
> could be deprecated slowly. BTW <code>#funcall</code> for the alternate
> private-accessing send is a <b>terrible</b> name, try
> <code>#instance_send</code>. (And yes, I'm begging here!)

I agree that `funcall' is a weird name... "call a function". What
function? I thought we agreed on calling them methods!


Cheers,
Daniel
Gregory B. (Guest)
on 2006-12-31 03:03
(Received via mailing list)
On 12/30/06, Daniel S. <removed_email_address@domain.invalid> wrote:

> > * Allow a comma between the two <code>alias</code> arguments --getting
> > an error on that is really annoying. Actually why is <code>alias</code>
> > a keyword? Why have both <code>#alias_method</code> and
> > <code>alias</code>? I have always been told that keywords were to be
> > avoided.
>
> I would personally prefer that the `alias' keyword be removed, but I
> have noticed how at least one prominent Rubyist, which has my utter
> respect, tends to use it all the time. Nonetheless, be gone with it!

+1

I think this is very much a situation where you can easily get by
without it and avoid ugliness / confusion.
Trans (Guest)
on 2006-12-31 04:15
(Received via mailing list)
Daniel S. wrote:

> I agree that `funcall' is a weird name... "call a function". What
> function? I thought we agreed on calling them methods!

This is kind of interesting. I don't know if matz had this in mind form
the beginning or only realized it later, but

  function = private method

why? because a private method can't be called with a receiver. it's a
very interesting correlation, which makes excellent sense. however, I
agree with you, introducing this concept into the language via a single
meta-coding method called 'funcall' is rather odd, to say the least
(okay, we have module_function too, but that certainly doesn't help
matters!!!)

T.
unknown (Guest)
on 2006-12-31 05:25
(Received via mailing list)
Hi --

On Sun, 31 Dec 2006, Daniel S. wrote:

> I agree that `funcall' is a weird name... "call a function". What
> function? I thought we agreed on calling them methods!

I think the idea is that calling methods without a receiver can be
considered "functional style"; therefore, "funcall", rather than
"send", should be understood to include private methods.

I'm not sure I find it very convincing.  I think of the no-receiver
thing as a way of un-cluttering the code a bit, not a departure from
object orientation.  After all, there *is* a receiver, and it is
receiving a message.

Also, funcall itself does involve a receiver.  So the situation is
that you see this:

   obj.funcall(:meth)

and you infer that it includes private methods because *if* you were
calling meth as a private method, there would be no receiver.  To me
that involves too much "What if?"


David
Suraj K. (Guest)
on 2006-12-31 06:45
unknown wrote:
> On Sun, 31 Dec 2006, Daniel S. wrote:
>
>> I agree that `funcall' is a weird name... "call a function". What
>> function? I thought we agreed on calling them methods!
>
> I think the idea is that calling methods without a receiver can be
> considered "functional style"; therefore, "funcall", rather than
> "send", should be understood to include private methods.

I think "funcall" is just an artifact of the rb_funcall()
function---which invokes a method on an _explicit_ receiver---from
Ruby's C interface.
Trans (Guest)
on 2006-12-31 07:23
(Received via mailing list)
removed_email_address@domain.invalid wrote:
>
> and you infer that it includes private methods because *if* you were
> calling meth as a private method, there would be no receiver.  To me
> that involves too much "What if?"


Hmm... Are you perhpas indirectly suggesting:

  send(:meth)  # private
  self.send(:meth)  # public

?

T.
Devin M. (Guest)
on 2006-12-31 08:11
(Received via mailing list)
Trans wrote:
> Hmm... Are you perhpas indirectly suggesting:
>
>   send(:meth)  # private
>   self.send(:meth)  # public
>
> ?

Yikes, a method that behaves differently depending on how it's called?
What about method(:send).call vs self.method(:send).call?

Meprefers send_priv or something.

Devin
(And I think David was just trying to guess at the reasoning behind the
name "funcall" [I'd imagine better explained by rb_funcall], and then
disagreeing with the reasoning.)
Eric H. (Guest)
on 2006-12-31 08:27
(Received via mailing list)
On Dec 30, 2006, at 14:47, Daniel S. wrote:

> I agree that `funcall' is a weird name... "call a function". What
> function? I thought we agreed on calling them methods!

Why? It looks like a function call as there is no receiver.

obj.foo() # method call, receiver is obj

foo() # function call, no receiver

private methods must be called like functions, not like methods.

--
Eric H. - removed_email_address@domain.invalid - http://blog.segment7.net

I LIT YOUR GEM ON FIRE!
Rob S. (Guest)
on 2006-12-31 09:39
(Received via mailing list)
On 12/31/06, Devin M. <removed_email_address@domain.invalid> wrote:
>
> Meprefers send_priv or something.
>
> Devin

What about:

obj.send(:foo) # will call only public
obj.send!(:foo) # will bypass private/protected, like the current send.

reads better then funcall to me, at least.
- Rob
Wilson B. (Guest)
on 2006-12-31 10:05
(Received via mailing list)
On 12/31/06, Rob S. <removed_email_address@domain.invalid> wrote:
> > What about method(:send).call vs self.method(:send).call?
> reads better then funcall to me, at least.
Yes please. That's perfect.
Eric H. (Guest)
on 2006-12-31 10:36
(Received via mailing list)
On Dec 31, 2006, at 24:04, Wilson B. wrote:
> On 12/31/06, Rob S. <removed_email_address@domain.invalid> wrote:
>> obj.send(:foo) # will call only public
>> obj.send!(:foo) # will bypass private/protected, like the current
>> send.
>>
>> reads better then funcall to me, at least.
>
> Yes please. That's perfect.

No please.  That doesn't match the behavior of any other #foo, #foo!
that I know of.  #send and #funcall match what the written methods
look like perfectly.

--
Eric H. - removed_email_address@domain.invalid - http://blog.segment7.net

I LIT YOUR GEM ON FIRE!
Trans (Guest)
on 2006-12-31 14:12
(Received via mailing list)
On Dec 31, 3:34 am, Eric H. <removed_email_address@domain.invalid> wrote:
> that I know of.  #send and #funcall match what the written methods
> look like perfectly.

The problem with #send and #funcall (or #send!) is that these are VIMs
(very important methods). They aren't to be overwritten lightly, if at
all, which is evident by the fact that we also have __send__ in case
that it is. So any generic piece of meta-programming ends up using
__send__ anyway. Throw in __funcall__ and now we have four methods when
two would do. So besides the fact that this straddles us with two
completely different terms for nearly the exact same thing, which is
bad enough, it does nothing to alleviate this more fundamental issue.

T.
unknown (Guest)
on 2006-12-31 14:12
(Received via mailing list)
Hi --

On Sun, 31 Dec 2006, Rob S. wrote:

>> What about method(:send).call vs self.method(:send).call?
> reads better then funcall to me, at least.
Me too -- that was what I suggested long ago :-)  Matz didn't feel it
corresponded to his concept of a ! (dangerous) method.


David
unknown (Guest)
on 2006-12-31 14:22
(Received via mailing list)
Hi --

On Sun, 31 Dec 2006, Eric H. wrote:

> know of.  #send and #funcall match what the written methods look like
> perfectly.

But #foo/#foo! behaviors don't have to match each other, except at the
very abstract level of one being "dangerous".  I've always thought
that including private methods vs. not including them was a good
candidate for dangerous, but Matz didn't agree in this case so I don't
think it will happen.

#send and #funcall sort of match what the written methods *might* look
like (sometimes; not in the case of setter methods, and not for public
methods where you used a receiver) if you called them.  It just seems
to me to be a pretty tenuous connection.


David
Martin DeMello (Guest)
on 2006-12-31 14:28
(Received via mailing list)
On 12/31/06, Suraj K. <removed_email_address@domain.invalid> wrote:
>
> I think "funcall" is just an artifact of the rb_funcall()
> function---which invokes a method on an _explicit_ receiver---from
> Ruby's C interface.

Ultimately, it's a lispism.

http://www.n-a-n-o.com/lisp/cmucl-tutorials/LISP-t...

martin
Mauricio F. (Guest)
on 2006-12-31 15:02
(Received via mailing list)
On Sun, Dec 31, 2006 at 09:20:34PM +0900, removed_email_address@domain.invalid 
wrote:
> >No please.  That doesn't match the behavior of any other #foo, #foo! that
> >I know of.  #send and #funcall match what the written methods look like
> >perfectly.
>
> But #foo/#foo! behaviors don't have to match each other, except at the
> very abstract level of one being "dangerous".  I've always thought
> that including private methods vs. not including them was a good
> candidate for dangerous, but Matz didn't agree in this case so I don't
> think it will happen.

Actually, in 1.9 you have send, funcall, __send and __send!.
These last ones might disappear at any time, but my hunch is that
there's a
chance they'll stay. But it's just the gut feeling of somebody who's
been
tracking Ruby 1.9 for a while and has seen features come by and go.

Reading the sources/changelogs periodically can be tiresome, so I've
been
maintaining this change summary for some time:

http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9#l22
unknown (Guest)
on 2006-12-31 15:10
(Received via mailing list)
Hi --

On Sun, 31 Dec 2006, Mauricio F. wrote:

>>>
> Actually, in 1.9 you have send, funcall, __send and __send!.
> These last ones might disappear at any time, but my hunch is that there's a
> chance they'll stay. But it's just the gut feeling of somebody who's been
> tracking Ruby 1.9 for a while and has seen features come by and go.

Thanks for the update.  I really must try to stay more on the edge of
1.9 :-)


David
Alex F. (Guest)
on 2006-12-31 17:20
(Received via mailing list)
> What about:
>
> obj.send(:foo) # will call only public
> obj.send!(:foo) # will bypass private/protected, like the current send.

I don't normally weigh in on these discussions, but since it's come up
again I'm strongly +1 for this.

> reads better then funcall to me, at least.

I know very little lisp, and though the private method == function link
makes sense, it's pretty esoteric.

I don't know what I'd expect a funcall method to do ... dial 0800 FUN
NOW ?

happy new year
alex
Yukihiro M. (Guest)
on 2006-12-31 20:07
(Received via mailing list)
Hi,

In message "Re: Little Things"
    on Sun, 31 Dec 2006 21:12:07 +0900, removed_email_address@domain.invalid 
writes:

|Me too -- that was what I suggested long ago :-)  Matz didn't feel it
|corresponded to his concept of a ! (dangerous) method.

I often change my mind, especially for 1.9.  See Mauricio's post in
[ruby-talk:231912].

							matz.
Yukihiro M. (Guest)
on 2006-12-31 20:35
(Received via mailing list)
Hi,

I'd like to see them as separated RCRs, even though the new RCR site
have not seen its successful start-up yet.

In message "Re: Little Things"
    on Sun, 31 Dec 2006 02:27:14 +0900, "Trans" 
<removed_email_address@domain.invalid>
writes:

|* Binding.of_caller. Yes, it's easy to abuse, and should be avoided at
|nearly all costs. But there are few pennies worth when nothing else
|will do. Some very cool metatricks are made possible by being able to
|access the caller's binding --the breakpoint lib being the most well
|known.

The biggest reason we don't have caller binding API is the difficulty
of the implementation under the current interpreter.  ko1 once said it
is possible for YARV, so all we need is to design good API.  I don't
think of_caller is the best name for it.

By the way, YARV was committed in the Subversion trunk yesterday.

|* <code>object_class</code> instead of </code>class</code>. I get sick
|just looking at <code>self.class.foo</code>. And it prevents use of
|"class" for other variables/methods. (Hence the all too frequent use of
|"klass"). <code>object_class</code> on the other hand is nicely
|analogous to <code>object_id</code>.

Could you describe what this change give you?  Removing class method
does not allow local variables to be named 'class'.  Besides that I
don't like the name "object_class", which is too vague for me.  class
of an object?  a class object?  an object which is a class?  whatever.
Maybe because I see many combination of "something id" but not
"something class", besides "business class" etc.

|* Allow a comma between the two <code>alias</code> arguments --getting
|an error on that is really annoying. Actually why is <code>alias</code>
|a keyword? Why have both <code>#alias_method</code> and
|<code>alias</code>? I have always been told that keywords were to be
|avoided.

Are you proposing comma between alias arguments, or removal of the
alias keyword?

|* <code>String#resc</code> as an inversion of
|<code>Regexp.escape(string)</code> and <code>String#to_re</code> as an
|inversion of <code>Regexp.new(string)</code>.

Why?

|* I'm dying here from remove_method hacks without
|<code>#instance_exec</code>. This has to rank in the top three "little
|things" that have been talked about forever, and it isn't that hard to
|implement. So what's holding it up?

We have it in 1.9.

|* A block can't take a block, nor default arguments. What kind of
|<code>define_method</code> is this? I realize this a trickier issue.
|But at some point the trick has to be performed.

We have it in 1.9; well, at least partially.

|* Close the closures. Writing DSLs is great, but have you noticed they
|all share the same closure? Have a way to reset the closure with some
|sort of special block notation would shore-up this danger hole. Maybe:
|
|<pre>
|  a = 1
|  dosomething do! |x|
|    p a  #=> error
|  end
|</pre>

I am not sure what you meant here.  Could you elaborate (maybe in a
separate post)?  Does any other language address this issue?

|* Another hassle when metaprogramming. <code>#send</code> should work
|for public methods only! There's a big issue with backward
|compatibility here. I have the solution: <code>#object_send</code>.
|It's a better name anyway b/c it stays out of the way (eg. my Email
|module would like to have a #send method, you dig?). And #send itself
|could be deprecated slowly. BTW <code>#funcall</code> for the alternate
|private-accessing send is a <b>terrible</b> name, try
|<code>#instance_send</code>. (And yes, I'm begging here!)

We have send, funcall, __send, __send! in 1.9.  Do we need more?

|* This one's more of my own pet-peeve but nontheless, who wouldn't want
|a nice word alias for Class#===. In most cases I prefer to read what
|I'm doing rather then recall the interpretation of a symbol. There are
|of course some symbols that are rather obvious, either by indication of
|their form (eg. <<) or by their widespread use (eg. =), but Class#===
|is not one of them. I would much prefer to see:
|
|  <pre>
|    MyClass.instance?(myobject)
|  </pre>
|
|But I'm not picky about what word to use as long as it's readable.

In short, you are asking for the alias for Module#===, right?
I don't see any good reason for it, where we can call

  myobject.instance_of?(MyClass)

but the good name for it would help accepting the proposal.

|* Oh, and lets not forget the forever arguable method name for (class
|<< self; self; end). But please give us something concise.

Yes, the name is the biggest obstacle now.

|No doubt there other little things left unmentioned, and obviously some
|are more important than others. But in any case, it's clearly striking
|that after hearing for so long about many such well-accepted "little
|things", that Ruby has yet to take them in. I have a silly theory about
|this actually --as odd as it may seem. The 1.9 version is the last on
|the chain before 2.0 b/c matz is against using double-digit minor
|numbers, eg 1.10. So we're is stuck with 1.9 as his test bed for 2.0.
|Since 1.8 can only increment by teeny, these "little things", being not
|little enough, can't make it in. Hence Ruby is being held back by a
|version number policy!!! I think Matz just needs to get on with it (hey
|look forward to 3.0!) or just lossen the version policy constraints.

Digits that we have many (hey, we could have 9 more major releases!)
are not the reason.  Expected screams from all over the world suspends
incompatibility and behavior changing for 1.8.

							matz.
Robert H. (Guest)
on 2006-12-31 20:40
Just one quick comment:

"[...] what could potentially kill the language.
We can have the best language on the Planet, but if the language
features are only accessible to those that are willing to go code-diving
for the answers, then the target audience is going to be slim."

I disagree to the potential of this.
I myself am sometimes annoyed at the lack of any
documentation, this sometimes involve old code - new code
almost always is nicely documented :)

However, only a lack of docu wont stop me from using
ruby. Most naturally because I do not HAVE to use 100%
of the language, and books like the pickaxe really
did help a LOT - IF any docu has to be added, then
i'd look at these things first ;)

- More focus on the C part of Ruby. Its a little bit
difficult to find enough good quality documents about
extending Ruby in C
- Allow only code into stdlib etc.. that has a minimum
docu
- Replacement for ri/rdoc or updating, so many people
rely on it for documenting their code, but the
html frame alone isnt always that appealing, and
ri can sometimes be slow, silly or... well
- Ruby website should offer online docu similar to how
php does. Php as a language is a curse, but the
online docu is rather good. I think ruby should
take up the idea of providing good online docu.

Anyway... just some of my long 2 cc, dont mean
to interrupt! :D
unknown (Guest)
on 2006-12-31 21:03
(Received via mailing list)
Hi --

On Mon, 1 Jan 2007, Yukihiro M. wrote:

> Hi,
>
> In message "Re: Little Things"
>    on Sun, 31 Dec 2006 21:12:07 +0900, removed_email_address@domain.invalid writes:
>
> |Me too -- that was what I suggested long ago :-)  Matz didn't feel it
> |corresponded to his concept of a ! (dangerous) method.
>
> I often change my mind, especially for 1.9.  See Mauricio's post in
> [ruby-talk:231912].

I saw -- it was a good reminder that I need to catch up on the latest
1.9's :-)


David
James G. (Guest)
on 2006-12-31 21:37
(Received via mailing list)
On Dec 31, 2006, at 12:34 PM, Yukihiro M. wrote:

> We have send, funcall, __send, __send! in 1.9.  Do we need more?

If __send! is OK, can we have the alias send! as well?  I thought we
wanted the get away from method names like __this__.

James Edward G. II
Devin M. (Guest)
on 2006-12-31 22:43
(Received via mailing list)
Yukihiro M. wrote:
> |* Oh, and lets not forget the forever arguable method name for (class
> |<< self; self; end). But please give us something concise.
>
> Yes, the name is the biggest obstacle now.
I take it you don't like meta_class, the most often proposed name for
it. How about virtual_class, or singleton_class, or both?

irb(main):001:0> a=5; def a.foo; end
TypeError: can't define singleton method "foo" for Fixnum
         from (irb):1
irb(main):002:0> a=""; class Foo < (class << a; self end); end
TypeError: can't make subclass of virtual class
         from (irb):2

:)

Devin
(Sorry, I don't know what's already been proposed. Shame on me for not
researching it...)
unknown (Guest)
on 2006-12-31 23:05
(Received via mailing list)
Hi --

On Mon, 1 Jan 2007, Devin M. wrote:

>        from (irb):1
> irb(main):002:0> a=""; class Foo < (class << a; self end); end
> TypeError: can't make subclass of virtual class
>        from (irb):2
>
> :)
>
> Devin
> (Sorry, I don't know what's already been proposed. Shame on me for not
> researching it...)

Just about every word in the English language, and a couple in German,
has been proposed :-)


David
Trans (Guest)
on 2007-01-01 00:36
(Received via mailing list)
removed_email_address@domain.invalid wrote:
> > about virtual_class, or singleton_class, or both?
> > Devin
> > (Sorry, I don't know what's already been proposed. Shame on me for not
> > researching it...)
>
> Just about every word in the English language, and a couple in German,
> has been proposed :-)

And one Latin ;-)

T.
Trans (Guest)
on 2007-01-01 01:42
(Received via mailing list)
Hey matz,

thanks for taking the time to respond to these.

> I'd like to see them as separated RCRs, even though the new RCR site
> have not seen its successful start-up yet.

If the RCR process gets fixed I would be happy to do some of them.
Right now only two people have submitted RCRs (last I checked) and the
communication on those RCRs is either broken or simply not being used
--I made attempts at emailing on the second --and I sumbitted the first
;-)

> The biggest reason we don't have caller binding API is the difficulty
> of the implementation under the current interpreter.  ko1 once said it
> is possible for YARV, so all we need is to design good API.  I don't
> think of_caller is the best name for it.

Really? By simply passing a block I can pass the binding of the caller.
I suppose passing a hidden block is too heavy though?

> By the way, YARV was committed in the Subversion trunk yesterday.

w00t!

> Could you describe what this change give you?  Removing class method
> does not allow local variables to be named 'class'.  Besides that I
> don't like the name "object_class", which is too vague for me.  class
> of an object?  a class object?  an object which is a class?  whatever.
> Maybe because I see many combination of "something id" but not
> "something class", besides "business class" etc.

The main thing is that it creates an exception b/c we are forced to use
a reciever, eg. self.class, so it can't be called as a "function" nor
made private. No other method is like that. Also I don't see why we
can't use it as a local var. Isn't the conflict with class<<obj
notation? Probably the parser should see /class\s+<</ as a whole unit,
which I think would allow for the var. But if you ask me the whole
"class << obj" notaton is yuk anyway. It visually clashes with Array#<<
and I'd much prefer someting like 'obj.meta_eval' -or-
'obj.singleton_eval'.

> |* Allow a comma between the two <code>alias</code> arguments --getting
> |an error on that is really annoying. Actually why is <code>alias</code>
> |a keyword? Why have both <code>#alias_method</code> and
> |<code>alias</code>? I have always been told that keywords were to be
> |avoided.
>
> Are you proposing comma between alias arguments, or removal of the
> alias keyword?

Well, both. First and foremost however is the option of a comma. What
good reson is there for getting getting a sytax error here?

As for makeing alias a real method, that seems like a good idea. it
would allow us to use 'alias' as a var too.

If it possible to get rid of an exception and have things still work
fine, then it's a good thing, isn't it?

> |* <code>String#resc</code> as an inversion of
> |<code>Regexp.escape(string)</code> and <code>String#to_re</code> as an
> |inversion of <code>Regexp.new(string)</code>.
>
> Why?

It's much more concise. Take a simple example:

  re = /^#{user_input}/

We need to escape it:

  re = /^#{Regexp.escape(user_input)}/

vs.

  re = /^#{user_input.resc}/

The to_re, just goes hand in hand with resc, since they both regular
expresions --maybe resc should be to_resc, but tersness is especially
useful with it so I suggest resc instead.

> |* I'm dying here from remove_method hacks without
> |<code>#instance_exec</code>. This has to rank in the top three "little
> |things" that have been talked about forever, and it isn't that hard to
> |implement. So what's holding it up?
>
> We have it in 1.9.

Yea! But why not a 1.8 serious. It's an additon it won't break
anything. Correct me if I'm wrong, but I fear we won't see anything
from 1.9 in production for almost 2 years.

>
> I am not sure what you meant here.  Could you elaborate (maybe in a
> separate post)?  Does any other language address this issue?

Okay. I will post separately.

> We have send, funcall, __send, __send! in 1.9.  Do we need more?

So we have the functionality. But can you tell me with a straight face
those are great method names?

Peronally, I really think you should get rid of __shadow methods
wherever you can. All it indicates is that the original method's name
is too common, so is likely to be overridden. And that's the reason I
suggest #object_send. All methods starting with object_ or instance_
are special. They are meta-programming methods and as such need to
stand aside in some fashion to avoid being overridden easily. This
consistancy is the beauty of it.

> In short, you are asking for the alias for Module#===, right?
> I don't see any good reason for it, where we can call
>
>   myobject.instance_of?(MyClass)
>
> but the good name for it would help accepting the proposal.

Yes. that's right. But I learned that it is better to ask the class if
you want to know the "truth". Sometimes the object might need to lie
--eg. as a proxy. I guess the most obvious name is:

  MyClass.class_of?(myobject)

> |* Oh, and lets not forget the forever arguable method name for (class
> |<< self; self; end). But please give us something concise.
>
> Yes, the name is the biggest obstacle now.

  #supercalifragilisticexpialidocius

Almost anything is better than nothing at this point.... okay maybe not
THAT, but you get my point.

> |look forward to 3.0!) or just lossen the version policy constraints.
>
> Digits that we have many (hey, we could have 9 more major releases!)

Good! :-)

> are not the reason.  Expected screams from all over the world suspends
> incompatibility and behavior changing for 1.8.

Yet most of these have no backward compatability issues --I guess
that's really my main point with "Little things"

Thanks and happy new year,
T.
Devin M. (Guest)
on 2007-01-01 03:10
(Received via mailing list)
Trans wrote:
> The main thing is that it creates an exception b/c we are forced to use
> a reciever, eg. self.class, so it can't be called as a "function" nor
> made private. No other method is like that.
Actually, two classes of method names come to mind:
- Those that share a name with a keyword (class, when, def, etc.)
- Setter methods (/=$/, that is)

There's an exception for the latter -- when private, they can be called
with self as an explicit receiver.

Neither defending the behavior nor arguing for a change... just playing
Mr. Fact Checker (or Mr. Obvious, depending on your POV).

Devin
Trans (Guest)
on 2007-01-01 04:18
(Received via mailing list)
Devin M. wrote:
> Trans wrote:
> > The main thing is that it creates an exception b/c we are forced to use
> > a reciever, eg. self.class, so it can't be called as a "function" nor
> > made private. No other method is like that.
> Actually, two classes of method names come to mind:
> - Those that share a name with a keyword (class, when, def, etc.)

That's a good point. Although 'when', 'def' and others aren't also
built-in methods. And in a private context at least, no one is going to
readily use them as such.

> - Setter methods (/=$/, that is)
>
> There's an exception for the latter -- when private, they can be called
> with self as an explicit receiver.

True. An expection I never liked, but it's neccessary, and at least
it's a very simple pattern.

> Neither defending the behavior nor arguing for a change... just playing
> Mr. Fact Checker (or Mr. Obvious, depending on your POV).

facts == good

Thanks,
T.
Yukihiro M. (Guest)
on 2007-01-01 06:30
(Received via mailing list)
Hi,

In message "Re: Little Things"
    on Mon, 1 Jan 2007 05:42:23 +0900, Devin M.
<removed_email_address@domain.invalid> writes:

|I take it you don't like meta_class, the most often proposed name for
|it. How about virtual_class, or singleton_class, or both?

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.
Gavin K. (Guest)
on 2007-01-01 07:50
(Received via mailing list)
Devin M. wrote:
> (Sorry, I don't know what's already been proposed. Shame on me for not
> researching it...)

For what it's worth, I started a wiki page a while ago (and others have
contributed) with the crazy huge list of suggested names, with some
discussion on some of them:

http://wiki.rubygarden.org/Ruby/page/show/Renaming...
unknown (Guest)
on 2007-01-01 15:33
(Received via mailing list)
Hi --

Happy New Year!

On Mon, 1 Jan 2007, Yukihiro M. wrote:

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

I don't think the "singleton" confusion is a big problem.  I've heard
many people say that it might be confusing, but very few people
actually be confused by it.  And if they are, it's worth the three
seconds it takes them to learn the difference :-)

Also, unless we're supposed to start using the term "eigenmethod" for
singleton methods, singleton_class is a better match in that sense.


David
Dave T. (Guest)
on 2007-01-01 16:39
(Received via mailing list)
>
> |I take it you don't like meta_class, the most often proposed name for
> |it. How about virtual_class, or singleton_class, or both?
>
> It's not really a meta class since it's not only for classes,
> nor virtual_class since it's not virtual anymore.

I wonder: is it a mistake to think of it as a class at all? Sure, it
had a 'class' somewhere in its background, but is potentially moved
on a lot since then. In a way, it's move analogous to a meta-binding,
as it's the execution environment of an object. So, just to get the
creative juices flowing, and in the spirit of brainstorming, how about

obj.personality

obj.capability

obj.implementation

Cheers


Dave
Yukihiro M. (Guest)
on 2007-01-01 16:59
(Received via mailing list)
Hi,

In message "Re: Little Things"
    on Mon, 1 Jan 2007 23:38:57 +0900, Dave T. 
<removed_email_address@domain.invalid>
writes:

|I wonder: is it a mistake to think of it as a class at all? Sure, it
|had a 'class' somewhere in its background, but is potentially moved
|on a lot since then. In a way, it's move analogous to a meta-binding,
|as it's the execution environment of an object. So, just to get the
|creative juices flowing, and in the spirit of brainstorming, how about
|
|obj.personality
|obj.capability
|obj.implementation

The "implemantation" is not what we're talking about.

The "personality" and "capability" of an object are characteristics of
the object, combined from attributes of its class and superclasses.
"That something" here is not these characteristics themselves, but a
handle to tweak them by per object basis.  Calling a handle by
characteristics may cause confusion.

							matz.
Yukihiro M. (Guest)
on 2007-01-01 17:01
(Received via mailing list)
Hi,

In message "Re: Little Things"
    on Mon, 1 Jan 2007 22:31:06 +0900, removed_email_address@domain.invalid 
writes:

|I don't think the "singleton" confusion is a big problem.  I've heard
|many people say that it might be confusing, but very few people
|actually be confused by it.  And if they are, it's worth the three
|seconds it takes them to learn the difference :-)
|
|Also, unless we're supposed to start using the term "eigenmethod" for
|singleton methods, singleton_class is a better match in that sense.

Makes sense.  Eigenmethods, hmm.

							matz.
Trans (Guest)
on 2007-01-01 17:05
(Received via mailing list)
Dave T. wrote:
> obj.implementation
That's an great perspective. Perhaps even different enough to get us
out of this quagmire.

Seems to me that 80% of the time we want to use the "singleton class"
with class_eval. Expressions like "singleton_class.class_eval" are
rather redundant and long winded (IMHO). So maybe another single term
for this, along the lines of what you're saying, would be better.
Looking at Phrogz' wiki page of names I came up with:

  customize do
    ...
  end

Then the class could be called the 'customization'. Ie. the above being
equvalent to:

  customization.class_eval do
    ...
  end

T.
Devin M. (Guest)
on 2007-01-01 18:37
(Received via mailing list)
Dave T. wrote:
> I wonder: is it a mistake to think of it as a class at all?
I don't think so, since class << Object.new; self end.is_a? Class. That
said, I'm not against names that don't involve the word 'class'.

> Then the class could be called the 'customization'.
Ooh... I like that.

Then all we need is a sentence in ri Class that reads 'Classes inherit
the customizations of their superclasses.' :)

Seriously. Rolls off the tongue. Simple. Descriptive. Plenty of
opportunities for variation -- plenty of ways to work into English
sentences.

In short: +1
Gregory B. (Guest)
on 2007-01-01 19:33
(Received via mailing list)
On 1/1/07, Trans <removed_email_address@domain.invalid> wrote:

>     ...
>   end

That sure looks pretty.  I do think maybe it'd be confusing to
remember where the code in the block to customize() is actually being
evaluated, but this could be a decent alternative.

Then again, I don't have any beef at all with singleton class/method
OR eigen class/method

I'd just like to see an end to (class << self; self; end) and
preferably avoid seeing 'meta' become part of method names, lest we
begin the meta_meta  and  the meta_meta_meta ;)
Simen E. (Guest)
on 2007-01-01 20:13
(Received via mailing list)
On 12/30/06, Trans <removed_email_address@domain.invalid> wrote:
> I was a bit surprised about Matz mention of the little things in his
> last <a
> href="http://www.rubyist.net/~matz/slides/rc2006/mgp0001....
> 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....
>  [...]

When we're talking about little things, I've got one suggestion as
well. Python has the nice trick that you can call any object like a
function by simply overriding the __call__ method. Something like that
would be nice to have in Ruby as well. When you call an object with
the normal syntax, the fallback could be the #call method or some
such. Then it'd be possible to do this:

  def some_method(&proc)
    proc("Hello")
    proc "Hello"
    proc 1, 2, 3
  end

I admit that having a separate function namespace means that we can
have ice syntax for method calls with no parens, but something like
this would permit some cool tricks.
Chris C. (Guest)
on 2007-01-01 20:21
(Received via mailing list)
On 1/1/07, Dave T. <removed_email_address@domain.invalid> wrote:
> as it's the execution environment of an object. So, just to get the
>
> Dave
>
>

I would like to put my vote in for

obj.super_ego
Gregory S. (Guest)
on 2007-01-01 23:38
(Received via mailing list)
On Tue, Jan 02, 2007 at 12:04:35AM +0900, Trans wrote:
} Dave T. wrote:
} > I wonder: is it a mistake to think of it as a class at all? Sure, it
} > had a 'class' somewhere in its background, but is potentially moved
} > on a lot since then. In a way, it's move analogous to a
meta-binding,
} > as it's the execution environment of an object. So, just to get the
} > creative juices flowing, and in the spirit of brainstorming, how
about
[...]

The only way in which a class and a module differ is that you can create
an
instance of a class. Current Ruby 1.8.5 will not let you call #new on a
singleton class, so one could argue that it's more a module than a
class,
remembering that Class subclasses Module. It is,
however, at least a module. It is very important that it can be treated
as
a module, i.e. responds to various methods defined in Module. I'd claim
that #include and #define_method are the two most important of those.

} Seems to me that 80% of the time we want to use the "singleton class"
} with class_eval. Expressions like "singleton_class.class_eval" are
} rather redundant and long winded (IMHO). So maybe another single term
} for this, along the lines of what you're saying, would be better.
} Looking at Phrogz' wiki page of names I came up with:
}
}   customize do
}     ...
}   end
}
} Then the class could be called the 'customization'. Ie. the above
being
} equvalent to:
}
}   customization.class_eval do
}     ...
}   end

If I hadn't had occasion to do significant metaprogramming and was
looking
at this, I'd agree with you that this is nice. As it is, there are
really
only four things I do to interact with the singleton class, in order of
frequency of use:

1) include a module
2) define a method
3) alias a method
4) remove a method

Now, #1 is served by Object#extend and doesn't require explicit access
to
the singleton class at all. With #2, 99% of the time I use
#define_method,
and the only time I don't is when I need to define a block-accepting
method. (Actually, I use send(:define_method, ...) because
#define_method
is private. Could we make #define_method public for all singleton
classes,
please? How about a SingletonClass subclass of Class, or possibly
module,
that makes it public?) I actually need #3 and #4 vanishingly rarely, and
most of the time it makes more sense to do it in a module anyway which
can
be included with extend.

I just realized I forgot attr_accessor and friends, but I'd be inclined
to
use #send (or #funcall) with that as well. What I'm saying, though, is
that
if I had #customize and #customization (and #define_method were public
for
singleton classes), I'd still do something like this (note: contrived
example):

def setup_hashed_attributes(obj, hash)
  if attrs = obj.instance_variable_get(:@hashed_attributes)
    attrs.merge(hash)
  else
    obj.instance_variable_set(:@hashed_attributes, hash.dup)
  end
  singleton = obj.customization
  singleton.send(:attr_reader, :hashed_attributes)
  hash.keys.each { |k|
    singleton.define_method(k) { @hashed_attributes[k] }
    singleton.define_method("#{k}=") { |v| @hashed_attributes[k] = v }
  }
end

...rather than the equivalent...

def setup_hashed_attributes(obj, hash)
  if attrs = obj.instance_variable_get(:@hashed_attributes)
    attrs.merge(hash)
  else
    obj.instance_variable_set(:@hashed_attributes, hash.dup)
  end
  obj.customize {
    attr_reader :hashed_attributes
    hash.keys.each { |k|
      define_method(k) { @hashed_attributes[k] }
      define_method("#{k}=") { |v| @hashed_attributes[k] = v }
    }
  }
end

I just like how the first one reads. The first one says, "I am messing
with
an object's capabilities by poking at its instance variables and adding
methods to it." The second one says, "I am reopening a class and adding
methods to it after poking at an instance variable."

} T.
--Greg
Trans (Guest)
on 2007-01-02 03:34
(Received via mailing list)
Gregory S. wrote:
> The only way in which a class and a module differ is that you can create an
> instance of a class. Current Ruby 1.8.5 will not let you call #new on a
> singleton class, so one could argue that it's more a module than a class,
> remembering that Class subclasses Module. It is,
> however, at least a module. It is very important that it can be treated as
> a module, i.e. responds to various methods defined in Module. I'd claim
> that #include and #define_method are the two most important of those.

Boy, I wish it were a module. That would make something a hek of a lot
easier. Personally I never cared for the distiction between Class and
Module. I feel it is rather arbitrary and I spend too much time wonder
which one I should use for a give case.

> Now, #1 is served by Object#extend and doesn't require explicit access to
> the singleton class at all. With #2, 99% of the time I use #define_method,
> and the only time I don't is when I need to define a block-accepting
> method. (Actually, I use send(:define_method, ...) because #define_method
> is private. Could we make #define_method public for all singleton classes,
> please? How about a SingletonClass subclass of Class, or possibly module,
> that makes it public?) I actually need #3 and #4 vanishingly rarely, and
> most of the time it makes more sense to do it in a module anyway which can
> be included with extend.

I'd put #2 before #1 and often 'def obj.meth' serves the purpose.

>     obj.instance_variable_set(:@hashed_attributes, hash.dup)
>   end
>   singleton = obj.customization
>   singleton.send(:attr_reader, :hashed_attributes)
>   hash.keys.each { |k|
>     singleton.define_method(k) { @hashed_attributes[k] }
>     singleton.define_method("#{k}=") { |v| @hashed_attributes[k] = v }
>   }
> end

I don't know. If you're going to go to all that trouble why bother with
the assignment? Just do:

 def setup_hashed_attributes(obj, hash)
   if attrs = obj.instance_variable_get(:@hashed_attributes)
     attrs.merge(hash)
   else
     obj.instance_variable_set(:@hashed_attributes, hash.dup)
   end
   obj.customization.send(:attr_reader, :hashed_attributes)
   hash.keys.each { |k|
     obj.customization.define_method(k) { @hashed_attributes[k] }
     obj.customization.define_method("#{k}=") { |v|
@hashed_attributes[k] = v }
   }
 end

That reads better IMO. You could alwasy add #define_custom_method too
of course.

T.
unknown (Guest)
on 2007-01-02 06:14
(Received via mailing list)
On Jan 1, 2007, at 4:36 PM, Gregory S. wrote:
> The only way in which a class and a module differ is that you can
> create an
> instance of a class.

Well that and the fact that class objects are organized in a tree via
inheritance.  Modules are not.

Gary W.
Paulo Köch (Guest)
on 2007-01-03 23:04
(Received via mailing list)
On 2006/12/31, at 07:38, Rob S. wrote:
> obj.send(:foo) # will call only public
> obj.send!(:foo) # will bypass private/protected, like the current
> send.

+1
unknown (Guest)
on 2007-01-03 23:08
(Received via mailing list)
On Thu, 4 Jan 2007, [ISO-8859-1] Paulo Köch wrote:

> On 2006/12/31, at 07:38, Rob S. wrote:
>> obj.send(:foo) # will call only public
>> obj.send!(:foo) # will bypass private/protected, like the current send.
>
> +1

++

-a
Robert D. (Guest)
on 2007-01-03 23:48
(Received via mailing list)
On 1/3/07, removed_email_address@domain.invalid 
<removed_email_address@domain.invalid> wrote:
>
> -a
> --
> if you find yourself slandering anybody, first imagine that your mouth is
> filled with excrement.  it will break you of the habit quickly enough. -
> the
> dalai lama
>
>
It is not frequent that I dare not do agree with Gurus like Ara (1) but
I
have a very strong feeling that the ! suffix should indicate an object
inplace change instead of the object not being touched, as e.g. in sub
vs.
sub! (2) etc.
I feel it is not a good idea to define send! as mentioned above.

Cheers
Robert

(1) See James I can define the experts ;) just kidding the expert thingy
is
dangerous stuff I agree fully!!!
(2) OT but still interesting I feel it might be a good convention that
any
method changing the object should have a ! suffix, would make
     programs much more readable, don't you think?

R.
--
"The real romance is out ahead and yet to come. The computer revolution
hasn't started yet. Don't be misled by the enormous flow of money into
bad
defacto standards for unsophisticated buyers using poor adaptations of
incomplete ideas."

- Alan Kay
unknown (Guest)
on 2007-01-03 23:54
(Received via mailing list)
Hi --

On Thu, 4 Jan 2007, Robert D. wrote:

> (2) OT but still interesting I feel it might be a good convention that any
> method changing the object should have a ! suffix, would make
>    programs much more readable, don't you think?

No.  I would not want to see pop turned into pop! or << turned into
<<! and so forth.


David
Trans (Guest)
on 2007-01-03 23:58
(Received via mailing list)
removed_email_address@domain.invalid wrote:
> On Thu, 4 Jan 2007, [ISO-8859-1] Paulo Köch wrote:
>
> > On 2006/12/31, at 07:38, Rob S. wrote:
> >> obj.send(:foo) # will call only public
> >> obj.send!(:foo) # will bypass private/protected, like the current send.
> >
> > +1
>
> ++

Come on guys. Has anyone read my critique? You can "plus one" til the
cow's come home, but you totally ignore the issues. Show me you know
something about the issue, tell me _why_. Otherwise  your +1's are
littel more than cooy feelings.

Do you understand that #send is tantamount to a keyword?

T.
unknown (Guest)
on 2007-01-04 00:06
(Received via mailing list)
Hi --

On Mon, 1 Jan 2007, Trans wrote:

> --I made attempts at emailing on the second --and I sumbitted the first
> ;-)

Can you tell me what happened when you tried the email?  Did you
subscribe to it at the site?  If something's wrong, I can't fix it
unless I hear about it.  If people are just not using the site much,
that's not the same as its being broken.


David
unknown (Guest)
on 2007-01-04 00:06
(Received via mailing list)
On Thu, 4 Jan 2007, Trans wrote:

>> ++
>
> Come on guys. Has anyone read my critique? You can "plus one" til the
> cow's come home, but you totally ignore the issues. Show me you know
> something about the issue, tell me _why_. Otherwise  your +1's are
> littel more than cooy feelings.
>
> Do you understand that #send is tantamount to a keyword?

yes.  but it's only keword-like without a receive and

   send! 'private_method'

is fine since

   private_method

is fine too.

-a
Trans (Guest)
on 2007-01-04 02:09
(Received via mailing list)
removed_email_address@domain.invalid wrote:
> >>> +1
> yes.  but it's only keword-like without a receive and
>
>    send! 'private_method'
>
> is fine since
>
>    private_method
>
> is fine too.

But it's the public use that actually causes the most trouble. It's
keyword-like in that it a method that is too important to override. So
we end up with __send__ or __send, which is ridiculous. Might as well
drop #send altogether and just have the ugly shadow method. Please, ask
yourselves, why do we have __send__?

T.
unknown (Guest)
on 2007-01-04 02:31
(Received via mailing list)
On Thu, 4 Jan 2007, Trans wrote:

>>
>> is fine too.
>
> But it's the public use that actually causes the most trouble. It's
> keyword-like in that it a method that is too important to override. So
> we end up with __send__ or __send, which is ridiculous. Might as well
> drop #send altogether and just have the ugly shadow method. Please, ask
> yourselves, why do we have __send__?
>
> T.

hmmm.  there is no way around this kind of thing unless the operation of
sending a message to an object is removed from the object's interface.
so we
could have something like

   Pervasives.send obj, message, *args, &block

here Pervasives is an object that cannot be changed - even by changing
Object#send.

this also allows

   Pervasives.object_id obj

etc.

thoughts?

-a
unknown (Guest)
on 2007-01-04 02:37
(Received via mailing list)
Hi --

On Thu, 4 Jan 2007, removed_email_address@domain.invalid wrote:

>>>
>> T.
> this also allows
>
>  Pervasives.object_id obj
>
> etc.
>
> thoughts?

I'm afraid I'm lost.  What's wrong with send, other than its
commonness as a name (which is dealt with by __send__)?  If it's too
much trouble to explain, that's OK.


David
unknown (Guest)
on 2007-01-04 02:49
(Received via mailing list)
On Thu, 4 Jan 2007 removed_email_address@domain.invalid wrote:

>> this also allows
>>
>>  Pervasives.object_id obj
>>
>> etc.
>>
>> thoughts?
>
> I'm afraid I'm lost.  What's wrong with send, other than its
> commonness as a name (which is dealt with by __send__)?  If it's too
> much trouble to explain, that's OK.

so long as we have to rely on objects responding to certain methods
certain
constructs, such as those that meta-programming cut to, can be made
difficult
since the very methods we require to operate can be over-ridden.  this
is why
we have

   __id__
   __send__

are examples.  by moving the essential methods outside of the object
itself an
into a frozen introspector

   Introspector.object_id obj

we can elimnate this gotcha and this code

   class BlankSlate
     instance_methods.each{|m| remove_method unless m[/__/]}
   end

can be reduced (and made more robust) to

   class BlankSlate
     instance_methods.each{|m| remove_method m}
   end

make sense?

-a
Gregory B. (Guest)
on 2007-01-04 02:51
(Received via mailing list)
On 12/31/06, Rob S. <removed_email_address@domain.invalid> wrote:
> On 12/31/06, Devin M. <removed_email_address@domain.invalid> wrote:

> What about:
>
> obj.send(:foo) # will call only public
> obj.send!(:foo) # will bypass private/protected, like the current send.

+1.  This sounds great.  (sorry for the late reply)
unknown (Guest)
on 2007-01-04 03:13
(Received via mailing list)
Hi --

On Thu, 4 Jan 2007, Gregory B. wrote:

> On 12/31/06, Rob S. <removed_email_address@domain.invalid> wrote:
>> On 12/31/06, Devin M. <removed_email_address@domain.invalid> wrote:
>
>> What about:
>>
>> obj.send(:foo) # will call only public
>> obj.send!(:foo) # will bypass private/protected, like the current send.
>
> +1.  This sounds great.  (sorry for the late reply)

BTW the earlier discussion of this, for those interested, starts at:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/...

So everyone be careful not to add your +1 if it's already there :-)


David
unknown (Guest)
on 2007-01-04 03:23
(Received via mailing list)
Hi --

On Thu, 4 Jan 2007, removed_email_address@domain.invalid wrote:

>>> Object#send.
>> commonness as a name (which is dealt with by __send__)?  If it's too
> are examples.  by moving the essential methods outside of the object itself
>
> can be reduced (and made more robust) to
>
>  class BlankSlate
>    instance_methods.each{|m| remove_method m}
>  end
>
> make sense?

It seems a bit drastic to flip things around into that less OO style.
I'm not too worried if something like BlankSlate has to jump through a
hoop or two.  In practice, has the name conflict issue with send
actually been much of a problem?


David
Trans (Guest)
on 2007-01-04 03:33
(Received via mailing list)
removed_email_address@domain.invalid wrote:
> > this also allows
> >
> >  Pervasives.object_id obj
> >
> > etc.
> >
> > thoughts?
>
> I'm afraid I'm lost.  What's wrong with send, other than its
> commonness as a name (which is dealt with by __send__)?  If it's too
> much trouble to explain, that's OK.

Precisely right -- both of you -- it just depends on your viewpoint:

1) There should be a unalterable means of dynamically sending a message
to an object. PERIOD. That seem reasonable, but...

2) one can argue #1 is rather non-OOP like and if someone wants to
monkey with the "send" method then that's their silly business.

So we have a choice, do we deviate from strict OOP, or do accept the
dangers of overridablity and recognize that generalized meta-code which
we except to work in all cases certainly will not.

Presently Ruby has adopted the 2nd approach, and uses the #send method
to do it. Unfortunately this method makes the danger of overridablity
even worse b/c, as David points out, it is also a rather common word.
So what happens? To mitigate the danger we get #__send__. This gives
some reassurance of guaranteed sendability while still being
overridable if absolutely necessary. Right? Unfortunately NO! It just
exacerbates the issue further. Not only is there's really no point to
using #send since all assurance rests in __send__, but the assurance
itself is an illusion b/c __send__ can be overridden. We've gained
nothing by this but additional complexity.

So we have a choice. Either pick option #1 instead. Or stick with #2
and choose a single method name that is relatively uncommon.

If Ruby sticks with #2 were actually in luck, there's already a
unspoken precedence for important meta-methods to stay out of the way
of common names, namely those prefixed with object_ (as in object_id)
and instance_ (as in instance_variable_get) One for public sending
(object_send) and one for private sending (instance_send) --at least in
MHO.

One last thing. Has anyone considered a magic dot notation to act as
sort of a window to private space? Eg. something like:

  obj.private.message

T.
matt (Guest)
on 2007-01-04 03:47
(Received via mailing list)
>
> 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
unknown (Guest)
on 2007-01-04 03:55
(Received via mailing list)
Hi --

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."


David
unknown (Guest)
on 2007-01-04 04:33
(Received via mailing list)
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

we are voting for, as opposed to against, the idea.

cheers.

-a
Gregory B. (Guest)
on 2007-01-04 04:33
(Received via mailing list)
On 1/3/07, removed_email_address@domain.invalid 
<removed_email_address@domain.invalid> wrote:
> >> obj.send!(:foo) # will bypass private/protected, like the current send.
> >
> > +1.  This sounds great.  (sorry for the late reply)
>
> BTW the earlier discussion of this, for those interested, starts at:
> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/...

David, thanks for linking this. It's good to see this has come up
before and have some additional context.
unknown (Guest)
on 2007-01-04 04:49
(Received via mailing list)
On Thu, 4 Jan 2007 removed_email_address@domain.invalid wrote:

>> make sense?
>
> It seems a bit drastic to flip things around into that less OO style.  I'm
> not too worried if something like BlankSlate has to jump through a hoop or
> two.

i wouldn't say it's less OO.  according to wikipedia

in fact, it's quite OO: Pervasives (Introspector or whatever we might
call it)
is the object that sees through to the pristine unalterable state of any
other
object.  it interacts with these other objects by sending messages.
this is
quite inline with any OO i've ever heard of, for instance

we might as well say something like

   Guru.send student, message, :compassion

http://en.wikipedia.org/wiki/Object_%28computer_science%29 seems to
agree
somewhat

   "In the programming paradigm, object-oriented programming, an object
is an
   individual unit of run-time data storage that is used as the basic
building
   block of programs. These objects act on each other, as opposed to a
   traditional view in which a program may be seen as a collection of
   functions, or simply as a list of instructions to the computer. Each
object
   is capable of receiving messages, processing data, and sending
messages to
   other objects.  Each object can be viewed as an independent little
machine
   or actor with a distinct role or responsibility."

i understand the sentiment.  still, what we after is a methodology which
ensures that some aspects of objects can always be reached.  it's quite
OO to
delegate the responsibility of locating and preserving that aspect to
another
object.  syntactically one might prefer

   reveal{ object }.send msg

but the impl would obviously be the same since, here, we've just popped
up to

   (Kernel|Object).reveal

remember that much of ruby works this way: puts, fork, exit, raise, etc
are
all hung off of Kernel|Object.

> In practice, has the name conflict issue with send actually been much of a
> problem?

yes. and the related object_id, instance_eval, instance_variable_get,
etc.
the fact that some, but not all, methods of an object are required for
it to
function at a reasonble level, and that those same methods are not
protected
or separated from 'normal' methods in any way has frequently been an
issue for
the few metaprogramming libs i've written such as traits, attributes,
xx, etc.

regards.

-a
Trans (Guest)
on 2007-01-04 04:51
(Received via mailing list)
Trans wrote:

> One last thing. Has anyone considered a magic dot notation to act as
> sort of a window to private space? Eg. something like:
>
>   obj.private.message

Duh... I did!

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/...

T.
Trans (Guest)
on 2007-01-04 04:57
(Received via mailing list)
removed_email_address@domain.invalid wrote:

> BTW the earlier discussion of this, for those interested, starts at:
> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/...

Wow. That's a great thread! I esspecially liked the idea of #send as
the methodized form of the dot. And Jacob F.'s insight that if send
called private and obj.send only prublic then

  class Object
    def instance_send( ... )
      send( ... )
    end
  end

can be used to bypass privacy.

The thread ends with a great analysis by Peter V. on how
Ruby's public vs. private and method_missing are not wholey consistant.

Thanks!
T.
Rob S. (Guest)
on 2007-01-04 05:07
(Received via mailing list)
On 1/3/07, removed_email_address@domain.invalid 
<removed_email_address@domain.invalid> wrote:
> >> obj.send!(:foo) # will bypass private/protected, like the current send.
> >
> > +1.  This sounds great.  (sorry for the late reply)
>
> BTW the earlier discussion of this, for those interested, starts at:
> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/...
>
> So everyone be careful not to add your +1 if it's already there :-)
>
>
> David

Huh - I'm glad to see you had the idea first, David.  I guess I get
good ideas at least once in awhile :).

- Rob
Trans (Guest)
on 2007-01-04 05:09
(Received via mailing list)
removed_email_address@domain.invalid wrote:
> in fact, it's quite OO: Pervasives (Introspector or whatever we might call it)
>
> ensures that some aspects of objects can always be reached.  it's quite OO to
> all hung off of Kernel|Object.
> regards.
you make a strong argument ara. i know we've discussed this particular
question before, i forget what we came up with then. i'll have to
search for it. but at the moment it would be nicer with a shorter
notation. what about some type of alternate "dot" that demands the Guru
module definition:

  obj$send message

or something. (Hmm... didn't someone suggest using the dollar sign in a
similar syntax before? What was that about?)

T.
James G. (Guest)
on 2007-01-04 05:35
(Received via mailing list)
On Jan 3, 2007, at 7:33 PM, Trans wrote:

> If Ruby sticks with #2 were actually in luck, there's already a
> unspoken precedence for important meta-methods to stay out of the way
> of common names, namely those prefixed with object_ (as in object_id)
> and instance_ (as in instance_variable_get) One for public sending
> (object_send) and one for private sending (instance_send) --at
> least in
> MHO.

We're not sending an object though, we're sending a message.  Perhaps
send_message() would be a less clashed name, but I doubt it.

James Edward G. II
Trans (Guest)
on 2007-01-04 05:59
(Received via mailing list)
James Edward G. II wrote:
> We're not sending an object though, we're sending a message.  Perhaps
> send_message() would be a less clashed name, but I doubt it.

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/...

Besides that would be "foo.send_object", not "foo.object_send".

T.
Rob S. (Guest)
on 2007-01-04 06:07
(Received via mailing list)
On 1/3/07, Trans <removed_email_address@domain.invalid> wrote:
>
> So what happens? To mitigate the danger we get #__send__. This gives
> If Ruby sticks with #2 were actually in luck, there's already a
> unspoken precedence for important meta-methods to stay out of the way
> of common names, namely those prefixed with object_ (as in object_id)
> and instance_ (as in instance_variable_get) One for public sending
> (object_send) and one for private sending (instance_send) --at least in
> MHO.

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.

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.

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.


- Rob
unknown (Guest)
on 2007-01-04 06:17
(Received via mailing list)
On Thu, 4 Jan 2007, Rob S. wrote:

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

agreed.

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

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.

regards.

-a
Devin M. (Guest)
on 2007-01-04 07:49
(Received via mailing list)
removed_email_address@domain.invalid wrote:
> so long as we have to rely on objects responding to certain methods certain
> constructs, such as those that meta-programming cut to, can be made
> difficult
> since the very methods we require to operate can be over-ridden.  this
> is why
> we have
>   __id__
>   __send__
Hrm. I thought the reason __id__ and __send__ where there was because id
and send are fairly common names and useful for custom methods in, say,
ActiveRecord::Base and Socket.

> are examples.  by moving the essential methods outside of the object
> itself an
> into a frozen introspector
>
>   Introspector.object_id obj
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!. That way you can have your BlankSlate and
eat it, too. Thoughts?

Devin
Trans (Guest)
on 2007-01-04 08:44
(Received via mailing list)
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 (Guest)
on 2007-01-04 08:58
(Received via mailing list)
Devin M. wrote:
> and send are fairly common names and useful for custom methods in, say,
> on __id, __send, and __send!.
Again, there would be no point in having #object_id, #send and #send!
in that case. If given a choice between a method that works and one
that might work, which one would you choose?

> That way you can have your BlankSlate and
> eat it, too. Thoughts?

__id__ ought to be deprecated. we have object_id.

T.
Martin DeMello (Guest)
on 2007-01-04 13:02
(Received via mailing list)
On 1/4/07, removed_email_address@domain.invalid 
<removed_email_address@domain.invalid> 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
Devin M. (Guest)
on 2007-01-04 14:30
(Received via mailing list)
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
unknown (Guest)
on 2007-01-04 15:12
(Received via mailing list)
Hi --

On Thu, 4 Jan 2007, removed_email_address@domain.invalid 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
unknown (Guest)
on 2007-01-04 15:14
(Received via mailing list)
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
Ilan B. (Guest)
on 2007-01-05 17:44
Trans wrote:
> I was a bit surprised about Matz mention of the little things in his
> last <a
> href="http://www.rubyist.net/~matz/slides/rc2006/mgp0001....
> 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
Jonas P. (Guest)
on 2007-01-06 20:30
(Received via mailing list)
2007/1/1, Yukihiro M. <removed_email_address@domain.invalid>:
> 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.
unknown (Guest)
on 2007-01-06 20:30
(Received via mailing list)
On Thu, 4 Jan 2007 removed_email_address@domain.invalid 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
unknown (Guest)
on 2007-01-06 20:30
(Received via mailing list)
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
Brian M. (Guest)
on 2007-01-06 20:30
(Received via mailing list)
On 1/4/07, removed_email_address@domain.invalid 
<removed_email_address@domain.invalid> 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 (Guest)
on 2007-01-06 20:30
(Received via mailing list)
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.
unknown (Guest)
on 2007-01-06 20:30
(Received via mailing list)
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 (Guest)
on 2007-01-06 20:31
(Received via mailing list)
removed_email_address@domain.invalid 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.
Evan W. (Guest)
on 2007-01-08 11:06
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.
unknown (Guest)
on 2007-01-08 14:43
(Received via mailing list)
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
James G. (Guest)
on 2007-01-08 15:10
(Received via mailing list)
On Jan 8, 2007, at 6:43 AM, removed_email_address@domain.invalid 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
Evan W. (Guest)
on 2007-01-08 17:48
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.
Evan W. (Guest)
on 2007-01-08 18:46
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...

Evan W.
unknown (Guest)
on 2007-01-19 17:29
(Received via mailing list)
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
unknown (Guest)
on 2007-01-19 17:30
(Received via mailing list)
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
unknown (Guest)
on 2007-01-19 17:30
(Received via mailing list)
On Fri, 5 Jan 2007 removed_email_address@domain.invalid wrote:

> method would be.
then you'd better not change it right!

;-)

-a
Trans (Guest)
on 2007-01-19 17:30
(Received via mailing list)
removed_email_address@domain.invalid wrote:

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

ara's right. having something like Pervasives would clean this whole
mess up.

though i want to point out, as things are, I think _why has pointed us
in the right direction when it comes to open apis. using dot-based
method_missing is passe. use '/' instead a la Hpricot.

still, the issue arises in more traditional api's too. and here again
all these pervasive methods would be best served with a Pervasives
module, or something equivalent.

but if that's not going to fly, then at the VERY LEAST these methods
must have relatviely uncommon names.

i think that's pretty much the bottom line.

T.
Trans (Guest)
on 2007-01-19 17:31
(Received via mailing list)
removed_email_address@domain.invalid wrote:
> 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.

Some how my original response this got lost. I'll just sum it up....

you are right. although with open api's, i think _why pointed us in
another direction: use '/' a la Hpricot and ditch method_missing. but
that doesn't solve the the issue for regular apis, and either we need
to do somethong like prevasives (I think module notation is too long)
or at the VERY LEAST, give these methods uncommon names.

T.
Trans (Guest)
on 2007-09-26 00:29
(Received via mailing list)
Joel VanderWerf wrote:

> My intuition is to make pervasive method calls a bit awkward and poorly
> syntactically supported, to discourage use outside of metaprogramming
> and hacking. You don't want ruby programmers to start using them by
> default instead of #class, #send, etc.

I'm a meta-programmer. Why does everyone keep trying to make my life
harder? ;-)

T.
Trans (Guest)
on 2007-09-26 00:29
(Received via mailing list)
removed_email_address@domain.invalid wrote:
> >>> If a ruby newbie tried "send" and saw it fail due to a private method,
> > then why not:
> >
> >  id!
> >  class!
> >  methods!
> >  ...etc...
> >
> > "!" means powerful!
>
> It means "dangerous", and I'm not sure what a dangerous id or class
> method would be.

I was just taking what you said to mean the #send itself was in the
"dangerous" group. maybe I miss read you. but taking that as basis, i
then though it's not really all that "dangerous", so I brought the idea
of "!" down a notch to meet it.

And it serves an extra needed purpose: adding a "!" helps overt
over-rides. So "!" would get the added distiction of "don't override"
in addition to "in place" and "dangerous".

I'm not advocating this neccessarily btw (I think '!''s are ugly). I'm
just exrapolating.

T.
unknown (Guest)
on 2007-09-26 00:31
(Received via mailing list)
On Fri, 5 Jan 2007, Trans wrote:

>
> though i want to point out, as things are, I think _why has pointed us
> in the right direction when it comes to open apis. using dot-based
> method_missing is passe. use '/' instead a la Hpricot.
>

but that doesn't work for beautiful things like

   task 'foo' do

   end

...

-a
Trans (Guest)
on 2007-09-26 00:32
(Received via mailing list)
Joel VanderWerf wrote:

> I'm sorry, T. You know I never meta-programmer I didn't like!

BTW LOL!

T.
Trans (Guest)
on 2007-09-26 00:33
(Received via mailing list)
Joel VanderWerf wrote:
> The values in the hash are always the original implementations.
>
> No new syntax or modules, just one new method.

Yes, that can be done. In fact:

require 'facets'
require 'kernel/as'

  "foo".as(Kernel).class #=> String

The thing is though, do you really way to put ".as(Kernel)." or
whateverfor every pervasive call?

I know Ara says he doesn't want to get rid of the orginal methods. But
then it marginizes the whole point of it. Either we are free to use
methods such as #class and #send for our own purposes or we are not.
Trying to have it both ways won't be nearly as effective. We will still
be afraid to override those methods. I'm not saying we have to get rid
of those methods neccessarily, but I am saying the pervasive methods
would/should become the more common form. So the syntax should be
something very concise.

T.
Chris C. (Guest)
on 2007-09-26 00:33
(Received via mailing list)
On 1/4/07, removed_email_address@domain.invalid 
<removed_email_address@domain.invalid> wrote:
> >
> in the practice of tolerance, one's enemy is the best teacher.
> - the dalai lama
>
>
I have been following this whole dicussion, and I think it is time to
put my two cents in, and summarize it.

We started not liking how #send would call private methods. and we
need it to not call them, but wait we need soemthing so we can call
those private methds.  The most commonly suggested method: #send!  But
#send still causes namespace issues.  The ultimate solution!...lots of
underscores.  We hate those too, hrm.  Lets add a new super
class/module/object/thing to the mix, called a Pervasive.  When we
need something not unique to a class we call it with Pervasive.method
obj.  Wait, then we do Pervasive.new(Foo, :args) every time, and we do
Pervasive.class obj a lot too.  This is super ugly, probably breaks
encapsulation, etc...  The solution, give the classes those methods,
and make them overriable, and also allow access to the object through
the Pervasive.  Problem here though, when writing a library we won't
know that someone overrode a method somewhere else in the chain, so we
are stuck using the Pervasive a lot anyway.  Why this isn't a problem
now you might ask?  Because we don't have the Pervasive, so people are
less willing to override those methods.  We still won't have a good
looking #send that calls private methds.  Well, we will, but it needs
a name.  I am willing to write up the RCR on this one.
unknown (Guest)
on 2007-09-26 00:33
(Received via mailing list)
On Fri, 5 Jan 2007, Chris C. wrote:

> obj.  Wait, then we do Pervasive.new(Foo, :args) every time, and we do
> Pervasive.class obj a lot too.  This is super ugly, probably breaks
> encapsulation, etc...  The solution, give the classes those methods,
> and make them overriable, and also allow access to the object through
> the Pervasive.  Problem here though, when writing a library we won't
> know that someone overrode a method somewhere else in the chain, so we
> are stuck using the Pervasive a lot anyway.  Why this isn't a problem
> now you might ask?  Because we don't have the Pervasive, so people are
> less willing to override those methods.  We still won't have a good
> looking #send that calls private methds.  Well, we will, but it needs
> a name.  I am willing to write up the RCR on this one.

bingo!

-a
Robert D. (Guest)
on 2007-09-26 00:34
(Received via mailing list)
On 1/5/07, Trans <removed_email_address@domain.invalid> wrote:
> harder? ;-)
>
> T.
>
>
> I guess meta-programming shall be harder until to the point where you
insert

require 'metakit'

into your programming, what about that idea?

Robert


--
"The real romance is out ahead and yet to come. The computer revolution
hasn't started yet. Don't be misled by the enormous flow of money into
bad
defacto standards for unsophisticated buyers using poor adaptations of
incomplete ideas."

- Alan Kay
Joel VanderWerf (Guest)
on 2007-09-26 00:34
(Received via mailing list)
Chris C. wrote:
...
> obj.  Wait, then we do Pervasive.new(Foo, :args) every time, and we do
> Pervasive.class obj a lot too.  This is super ugly, probably breaks
> encapsulation, etc...  The solution, give the classes those methods,
> and make them overriable, and also allow access to the object through
> the Pervasive.  Problem here though, when writing a library we won't
> know that someone overrode a method somewhere else in the chain, so we
> are stuck using the Pervasive a lot anyway.  Why this isn't a problem
> now you might ask?  Because we don't have the Pervasive, so people are
> less willing to override those methods.  We still won't have a good
> looking #send that calls private methds.  Well, we will, but it needs
> a name.  I am willing to write up the RCR on this one.

Thanks for the summary, Chris.

Could this be solved by having a hash of method objects, accessed
through a method on Kernel?

pm = Kernel.pervasive_methods

m = pm["class"] # => #<UnboundMethod: Object#class>
"foo".bind(m).call #=> String

The values in the hash are always the original implementations.

No new syntax or modules, just one new method.
unknown (Guest)
on 2007-09-26 00:37
(Received via mailing list)
Hi --

On Fri, 5 Jan 2007, Trans wrote:

> ara's right. having something like Pervasives would clean this whole
> mess up.

I'm not sure I think Ruby has to give priority to being able to serve
as host language for sub-languages that are in conflict with the core
methods and idioms of Ruby.

> though i want to point out, as things are, I think _why has pointed us
> in the right direction when it comes to open apis. using dot-based
> method_missing is passe. use '/' instead a la Hpricot.

It's not a winner-take-all thing,though; just use whatever makes sense
for what you're doing.  (Not that I want to encourage the magic dot
:-) (But still, there are lots of possibilities.)

I admit I don't like the name "Pervasives".  I could imagine some
class methods on Kernel, possibly, as a kind of back-stop for the
regular existing methods (i.e., I don't want to *have* to do the more
functional style if I don't want to).


David
unknown (Guest)
on 2007-09-26 00:38
(Received via mailing list)
On Fri, 5 Jan 2007 removed_email_address@domain.invalid wrote:

>>> to run un-attended for months on end get stomach cramps over.
>>
>> ara's right. having something like Pervasives would clean this whole
>> mess up.
>
> I'm not sure I think Ruby has to give priority to being able to serve
> as host language for sub-languages that are in conflict with the core
> methods and idioms of Ruby.

it already has.  it's called 'rake' and 'rails' and 'xml builder' and
'rant'
and 'xx' and 'rhdl' and etc etc...

you've read the rails source so i know you know what i'm talking about.

>
> It's not a winner-take-all thing,though; just use whatever makes sense
> for what you're doing.  (Not that I want to encourage the magic dot
> :-) (But still, there are lots of possibilities.)
>
> I admit I don't like the name "Pervasives".  I could imagine some
> class methods on Kernel, possibly, as a kind of back-stop for the
> regular existing methods (i.e., I don't want to *have* to do the more
> functional style if I don't want to).
>

precisely!  i'm not hung up on the name either, and i'm NOT advocating
removing any existing methods whatsoever: just the creation of a single
backdoor instead of '__method__', or 'method!' crazy proliferation: it
simply
does not scale, is not robust, and has code smell in the sense that the
containment is not OO (one object repsonsible) but is scattered all over
the
place via naming conventions.

cheers.

-a
unknown (Guest)
on 2007-09-26 00:39
(Received via mailing list)
On Fri, 5 Jan 2007 removed_email_address@domain.invalid wrote:


>
> Ah ha, my OO-er than thou claim comes back to haunt me! :-)  I actually
> don't usually talk in terms of more/less OO, and I know I'm guilty of
> introducing that into this discussion... but I will say that I don't think
> "one object responsible" is a principle of OO.  It may be that the ability
> to override send is a problem, but obj.send("message") is, I think, a pretty
> object-oriented way to go about things.
>

heh.  i think we're all in agreement then.  something should be done so
encapsulate the notion of 'this must always work' for a certain group of
methods.  i'm for a module/syntax based solution or, at the very least,
a
consistent naming convention.  if you're reading matz, what do you
think?

is anyone feeling up to summarizing and making a RCR?

-a
Joel VanderWerf (Guest)
on 2007-09-26 00:45
(Received via mailing list)
Trans wrote:
> Joel VanderWerf wrote:
>
>> My intuition is to make pervasive method calls a bit awkward and poorly
>> syntactically supported, to discourage use outside of metaprogramming
>> and hacking. You don't want ruby programmers to start using them by
>> default instead of #class, #send, etc.
>
> I'm a meta-programmer. Why does everyone keep trying to make my life
> harder? ;-)

I'm sorry, T. You know I never meta-programmer I didn't like!
Devin M. (Guest)
on 2007-09-26 00:48
(Received via mailing list)
removed_email_address@domain.invalid wrote:
> i'm NOT advocating removing any existing methods whatsoever
Ahh... my bad. Now I capisce. Object#class will be the "Please, fool me
with your crazy proxies and your metahackery!" version, and
Pervasives::class will be the "I am smarter than you. Don't you dare try
to trick me," version.

--1 (retraction, that is)

Devin
Robert D. (Guest)
on 2007-09-26 00:49
(Received via mailing list)
On 1/5/07, Trans <removed_email_address@domain.invalid> wrote:
> Could be a great one! My only concern is that having both the normal
> #send, etc. and the meta-forms (whatever the syntax) could lead to some
> sort of conflict that will defeat the purpose of even havnig a
> "metakit". I may be totally wrong about that though --it's just a "gut"
> worry.


I learned to respect your instincts, so this is probably an issue, but
do
you not think that it  is as a matter of fact an issue which a metakit
would
rather reduce than augment?
I imagine everything wrapped up in a module and some tricky mechanism in
metakit to allow to play some tricks with this module.

1st thought:
---------------
require 'metakit'

anObject.send  # still the old one
meta_import :send
anObject.send  # the new one
anObject.__orig_send # the old one, but this is somehow a snake biting
itself into its tail, I guess I read you better now!!

Scoping sometimes makes things clearer what about

2nd thought
---------------
require 'matakit'

meta_import :send do
### even meta_import :send => Object, :blah => Kernel do ....
   anObject.send  # the new one :)
end
anObject.send  # the old one :)

Cheers
Robert

> T.
>
>
>
--
"The real romance is out ahead and yet to come. The computer revolution
hasn't started yet. Don't be misled by the enormous flow of money into
bad
defacto standards for unsophisticated buyers using poor adaptations of
incomplete ideas."

- Alan Kay
unknown (Guest)
on 2007-09-26 00:49
(Received via mailing list)
Hi --

On Fri, 5 Jan 2007, removed_email_address@domain.invalid wrote:

> backdoor instead of '__method__', or 'method!' crazy proliferation: it simply
> does not scale, is not robust, and has code smell in the sense that the
> containment is not OO (one object repsonsible) but is scattered all over the
> place via naming conventions.

Ah ha, my OO-er than thou claim comes back to haunt me! :-)  I
actually don't usually talk in terms of more/less OO, and I know I'm
guilty of introducing that into this discussion... but I will say that
I don't think "one object responsible" is a principle of OO.  It may
be that the ability to override send is a problem, but
obj.send("message") is, I think, a pretty object-oriented way to go
about things.


David
unknown (Guest)
on 2007-09-26 00:49
(Received via mailing list)
On Fri, 5 Jan 2007, Devin M. wrote:

> removed_email_address@domain.invalid wrote:
>> i'm NOT advocating removing any existing methods whatsoever
> Ahh... my bad. Now I capisce. Object#class will be the "Please, fool me with
> your crazy proxies and your metahackery!" version, and Pervasives::class will
> be the "I am smarter than you. Don't you dare try to trick me," version.
>
> --1 (retraction, that is)

yeah.  sorry if i was unclear about that.

cheers.

-a
Joel VanderWerf (Guest)
on 2007-09-26 00:50
(Received via mailing list)
Trans wrote:
...
> require 'facets'
> require 'kernel/as'
>
>   "foo".as(Kernel).class #=> String

Nice!

> something very concise.
My intuition is to make pervasive method calls a bit awkward and poorly
syntactically supported, to discourage use outside of metaprogramming
and hacking. You don't want ruby programmers to start using them by
default instead of #class, #send, etc.
Trans (Guest)
on 2007-09-26 00:53
(Received via mailing list)
Robert D. wrote:
> I guess meta-programming shall be harder until to the point where you
> insert
>
> require 'metakit'
>
> into your programming, what about that idea?

Could be a great one! My only concern is that having both the normal
#send, etc. and the meta-forms (whatever the syntax) could lead to some
sort of conflict that will defeat the purpose of even havnig a
"metakit". I may be totally wrong about that though --it's just a "gut"
worry.

T.
This topic is locked and can not be replied to.