On Fri, 5 Jan 2007 [email protected] wrote:
method would be.
then you’d better not change it right!
-a
[email protected] 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.
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.
[email protected] 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.
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
Joel VanderWerf wrote:
I’m sorry, T. You know I never meta-programmer I didn’t like!
BTW LOL!
T.
[email protected] 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.
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.
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
On 1/4/07, [email protected] [email protected] 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.
On 1/5/07, Trans [email protected] 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
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.
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
On Fri, 5 Jan 2007 [email protected] 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
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
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!
On Fri, 5 Jan 2007 [email protected] wrote:
Ah ha, my OO-er than thou claim comes back to haunt me!
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
[email protected] 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
On 1/5/07, Trans [email protected] 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
On Fri, 5 Jan 2007, Devin M. wrote:
[email protected] 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
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.