Little Things

[ara.t.howard]

It means "dangerous", and I'm not sure what a dangerous id or class
method would be.

then you'd better not change it right!

;-)

-a

 

[Trans]

Hi --



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


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.

 

[Trans]

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.

 

[dblack]

Hi --

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

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

 

[ara.t.howard]

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

 

[ara.t.howard]

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

 

[dblack]

Hi --

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.

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

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

 

[Trans]

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.

 

[ara.t.howard]

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

 

[Chris Carter]

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

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.

 

[ara.t.howard]

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.

bingo!

-a

 

[Trans]

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.

An RCR for Pervasives? If so I'd like to add a note...

Using Pervasives means an object won't be able to trick you. Is that
good? If my class is a proxy then shouldn't it be able to trick you?
I'm not sure about this, maybe that's just foolish when it comes to
fundamental properties like class and id.

Also, if we have both pervasive methods PLUS the methods we presently
use, then we have the issue of inconsistancy. My object says it's a
"PeterPiper" but Pervasives say it's a "PickedPepper". Obviously
Pervasives is right, so what's the point of ever using the normal
method? Even if you know your own class in and out, you never know when
some one might come along and want to extend it. B/c of this Pervasives
would deservidely become common usage, so there should be a concise
syntax for it. "Pervasives.send obj, message" IMO is too long.

T.

 

[ara.t.howard]

"Pervasives.send obj, message" IMO is too long.

P = Pervasives

P.send obj, message

??

-a

 

[Tim Pease]

P = Pervasives

P.send obj, message

??

Why not get rid of Pervasives / P altogether and simply have some new
keywords in the parser?

send obj message
id obj


Blessings,
TwP

 

[ara.t.howard]

Why not get rid of Pervasives / P altogether and simply have some new
keywords in the parser?

shorter would be better alright.

send obj message
id obj

it __has__ to hang of another object otherwise

class C
def foo
send :inspect # keyword or method?
end
end

still. shorter is good. maybe something like

__( obj ).send message

where '__' returns a proxy for Pervasives?

-a

 

[Trans]

P = Pervasives

P.send obj, message

??

Well, that's shorter, yes. Though I was thinking more along the lines
of something unique.

Alternate to dot:

obj$send message

Or maybe

obj!send message

Global method:

$send obj, message

Or maybe reuse $. (and make input line number something else):

$.send obj, message

T.

 

[Tim Pease]

shorter would be better alright.


it __has__ to hang of another object otherwise

class C
def foo
send :inspect # keyword or method?
end
end

Hmmm ... maybe I need some enlightening, but this is what I came up with ...

cat a.rb

def if(*a) p a end

if true then puts 'keyword 1' end

if(true)
puts 'keyword 2'
end

ruby a.rb

keyword 1
keyword 2


That's the beauty of keywords -- the parser is going to intercept them
and invoke the appropriate function via the lexer. Unless I did not
properly define my "if" method there.

TwP

 

[ara.t.howard]

Or maybe

obj!send message

that's pretty good. i was leaning towards a module so we could just try to
write it as an extension now though...

-a

 

[ara.t.howard]

Hmmm ... maybe I need some enlightening, but this is what I came up with ...

def if(*a) p a end

if true then puts 'keyword 1' end

if(true)
puts 'keyword 2'
end

keyword 1
keyword 2


That's the beauty of keywords -- the parser is going to intercept them
and invoke the appropriate function via the lexer. Unless I did not
properly define my "if" method there.

my mistake. still, it'd be cool to see if we could hack into the current
ruby... though i've no idea if that's possible attm.

-a

 

[Trans]

that's pretty good. i was leaning towards a module so we could just try to
write it as an extension now though...

irb(main):003:0> class Object
irb(main):004:1> def p(obj=(not_obj=true;nil))
irb(main):005:2> return Pervasives if not_obj
irb(main):006:2> super obj
irb(main):007:2> end
irb(main):008:1> end
=> nil
irb(main):009:0> module Pervasives
irb(main):010:1> module_function
irb(main):011:1> def send(obj, *args, &blk)
irb(main):012:2> obj.send(*args,&blk)
irb(main):013:2> end
irb(main):014:1> end
=> nil
irb(main):015:0> p "2"
"2"
=> nil
irb(main):016:0> p.send("2",:class)
=> String
irb(main):017:0> p.send "2", :class
=> String

Then go "p p" ;-)

T.