However, that is only a convention, and is not enforced. Some libraries, like "mathn", don't define any new modules or classes, but instead (ab)use the metaprogramming and reflective capacities of Ruby and modify existing modules / classes by defining new methods or changing the behaviour of existing ones.
This should be discouraged or at least a consistent alternative. In any event, if it were possible to identify methods that require more than the stdlib or core....
Good luck finding support for that. Of course, noone dabbles into this sort of voodoo without his metaprogramming helmet. Banging your head against the wall in frustration at stuff not working can result in severe head trauma. Ruby allows you to do this sort of magic, and do it definately more easily and cleanly than in other languages directly manipulating superclass lists and property dictionaries and all such foolishness. This is a very distinctive feature of Ruby, and no chance in hell it's getting nerfed or discouraged. It's runninf with scissors, but sometimes you need to cut something really quickly
Can't disagree with the need.
But if the person doing the running doesn't know they are carrying scissors......
The other issue I'm running into is that out of three people and four machines, I only have one that lists mathn functions in 'ri' even though it's supposed to be in the standard library (v1.8). So you can imagine the confusion we are all having with me pulling methods out of thin air that no one else can even see.
I haven't been able to put together enough of a picture on the docs part of the issue to know where the problem lies, me, the distros (several) or RDocs. It's just an observation.
I'm not giving up. I feel I've just fallen with the scissors and skinned my knee.
···
On Mon, 16 Jan 2006 22:27:37 +0100, Tom Allison <tallison@tacocat.net> > wrote:
It depends what you mean by actively. Dozens of people have certainly
counseled against it, over the years. The difficulty, for me, has
always been how to harness this particular kind of flexibility and
openness, a prospect I've always found more intriguing than the
prospect of just deciding that it exists for the purpose of being
avoided. I think that if Ruby 2.0 has selector namespaces, we'll
probably see some very creative and productive runtime class changing.
Nevertheless, it's nice to have it there. Heck, Rails runs on so much deep magic it ain't pretty, if it's not actually changing core libraries. And selector namespaces sound like a nice way to prevent gods know what including gods know what gods know where, causing the mother of all obscure bugs sooner or later.
Or maybe not. I've heard extremely little about anyone actually using
any of the libraries that make block-scoped core changes possible.
Maybe there isn't all that great a demand for orderly ways to do it.
Well d'oh. They're rare, and they usually give unconventional behaviour to existing code, I'd be very surprised if they were present in stable prouction-code due to the risks involved. But if I wanted to make lessay a symbolic calculator, the tweaks made by "mathn" would come in handy. And having Kernel#y present for YAML pretty-printed inspect is also very convenient, and I'd rather have it than read the slightly ugly *ducks* default inspects, or have to type explicit namespace references for something that trivial and frequently used.
David Vallner
···
On Tue, 17 Jan 2006 04:05:00 +0100, <dblack@wobblini.net> wrote:
On Tue, 17 Jan 2006 04:05:00 +0100, <dblack@wobblini.net> wrote:
Or maybe not. I've heard extremely little about anyone actually using
any of the libraries that make block-scoped core changes possible.
Maybe there isn't all that great a demand for orderly ways to do it.
Well d'oh. They're rare, and they usually give unconventional behaviour to existing code, I'd be very surprised if they were present in stable prouction-code due to the risks involved.
I think we're talking about two different things. I'm referring to
Ruby Behaviors, Import Module, and a third project whose name I can't
remember but which does something similar: allow for temporary changes
to core classes.
David
--
David A. Black
dblack@wobblini.net
"Ruby for Rails", from Manning Publications, coming April 2006!
Heh, apparently, I had the standard modification of existing classes in mind, without extra scoping libraries all the time. Happens. I blame the caffeine.
David Vallner
···
On Tue, 17 Jan 2006 14:37:50 +0100, <dblack@wobblini.net> wrote:
I think we're talking about two different things. I'm referring to
Ruby Behaviors, Import Module, and a third project whose name I can't
remember but which does something similar: allow for temporary changes
to core classes.
I think we're talking about two different things. I'm referring to
Ruby Behaviors, Import Module, and a third project whose name I can't
remember but which does something similar: allow for temporary changes
to core classes.
David
Heh, apparently, I had the standard modification of existing classes in mind, without extra scoping libraries all the time. Happens. I blame the caffeine.
My segue from the first of those topics to the second may have been
unclear. I agree that changing core/standard classes, in code that is
going to be shared, is a bad idea. My first round of thinking through
this problem (expressed in ruby-talk:14556) led me to write Ruby
Behaviors, the main positive effect of which (since it's not much more
than a proof-of-concept library) was to spark a discussion at RubyConf
2001 about selector namespaces... and hopefully that will bear fruit
in Ruby 2.x.
David
···
On Wed, 18 Jan 2006, David Vallner wrote:
On Tue, 17 Jan 2006 14:37:50 +0100, <dblack@wobblini.net> wrote:
--
David A. Black
dblack@wobblini.net
"Ruby for Rails", from Manning Publications, coming April 2006!
