Robert Dober wrote:
> On Tue, Feb 26, 2008 at 4:52 PM, James Gray <james@grayproductions.net> wrote:
>> On Feb 26, 2008, at 9:45 AM, Jones, Brian - McClatchy Interactive wrote:
>>
>> > I'd be at least a little interested in potentially offering developers
>> > the chance to 'lock' their classes from monkey patches.
>>
>> There are probably ways around this, but:
> Hmm I do not think that one can overrule freeze; I never found a way,
> anyone else?
> Cheers
> Robert

You can monkeypatch Class#freeze, as long as you get there first

class Class
def freeze; end
end

class Foo
def bar; end
end

Foo.freeze

class Foo
def zap; end
end


--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

On Feb 26, 9:44 pm, furtive.cl...@gmail.com wrote:
> On Feb 26, 11:34 am, ThoML <micat...@gmail.com> wrote:
>
> > [...]
> > My point rather is this should somehow be standardized, i.e. the standard
> > library should provide standard means to do this.
>
> This is what I was attempting to say in my previous post on this
> thread. You mentioned defadvice, which is a good example of a "long
> reach" mechanism employed by top-level code in order to tweak lower-
> level code. The reason this thread exists is because there is no
> centralized mechanism in ruby to programmers from stepping on
> each others' toes. Making ad hoc modifications to base-level classes
> is not a scalable practice.
>
> So I will ask my question again: Is (or was) there a serious plan for
> something like selector namespaces in ruby 2.0? I foundhttp://rubygarden.org/ruby/page/show/Rite
> which appears to be down; google cache:http://64.233.169.104/search?q=cache...arden.org/ruby...

Solutions to this tend to be pretty weighty. Ruby is already a rather
slow language. A while back I suggested this idea:

module MyModule
class String < ::String
def something; "something"; end
end

def self.tryme
"string".something
end
end

def tryme2
"string".something
end

MyModule.tryme #=> "sometging"
tryme2 #=> NoMethodError

Austin thought it was the worst idea in the world. He may be right,
I'm not sure. In either case it would add another level of
consideration to the language.

> Responses such as "What is the problem?" come from those who have been
> lucky enough to evade these issues in their own work. But eventually
> one will wish to use some code written by someone else which
> introduces conflicts. It's only a matter of time, unless you
> personally write every line of code in your project. So the answer to
> "What is the problem?" is that the technique doesn't scale.

What technique is perfectly scalable? There is always the potential of
name clash no matter what technique is used. It's an unfortunate fact
of life, but if the library you are trying to use is poorly written --
well, then life sucks. Fix the library or find another.

I think you may be looking foe a magic bullet that doesn't exist.
Also, do you have examples of this issue?

T.

On Tue, Feb 26, 2008 at 7:25 PM, James Britt <james.britt@gmail.com> wrote:
> Code that is poorly written or does not play well with others tends to
> get discarded.

We still have Gems, which don't play well at all with others (on a
technical basis) - witness the conflicts with the Debian team, and
what every other Unix package maintainer says about this. This proves
that this mechanism doesn't work so well if there is a size/momentum
advantage.

Also, discussing what is appropriate and not is a good way to educate
people, and to us all learn to think more clearly in the area.

Eivind.

On Feb 24, 2008, at 10:02 PM, James Gray wrote:

> On Feb 23, 2008, at 4:23 PM, Eric Mahurin wrote:
>
>> I usually only do monkey patching in the
>> following cases which have no reuse: top-level script, testing, and
>> quick hacking.
>
> I think it's the ideal tool for adding compatibility methods.

Along these lines, I read a chapter in Design Patterns in Ruby last
night that suggests using Ruby's open classes as one possible way to
implement the Adapter pattern. The book includes a pretty good
discussion of the plusses and minus to this approach and makes
recommendations about when it's probably worth the trade-off. It's a
good read.

James Edward Gray II

> On Tue, Feb 26, 2008 at 1:25 PM, James Britt=20
> <james.britt@gmail.com> wrote:
> > It's not that these claims are entirely untrue, it's just that, in=20
> > real life, most people simply do not encounter the =20
> alleged problems.
> >
> > Code that is poorly written or does not play well with=20
> others tends=20
> > to get discarded.
>=20
> Except that I'm working in the real world, and I run into=20
> these problems practically every day. =20

It may be enough to simply have ruby warn us when and where a class has
been re-opened and a means to ignore it by file/path or namespace if we
want.

Brian

[Note: parts of this message were removed to make it a legal post.]

On Wed, Feb 27, 2008 at 7:46 AM, James Gray <james@grayproductions.net>
wrote:

> On Feb 24, 2008, at 10:02 PM, James Gray wrote:
>
> > On Feb 23, 2008, at 4:23 PM, Eric Mahurin wrote:
> >
> >> I usually only do monkey patching in the
> >> following cases which have no reuse: top-level script, testing, and
> >> quick hacking.
> >
> > I think it's the ideal tool for adding compatibility methods.
>
> Along these lines, I read a chapter in Design Patterns in Ruby last
> night that suggests using Ruby's open classes as one possible way to
> implement the Adapter pattern. The book includes a pretty good
> discussion of the plusses and minus to this approach and makes
> recommendations about when it's probably worth the trade-off. It's a
> good read.
>
> James Edward Gray II


I don't have the book. I wouldn't mind seeing the +/- list.

You are talking about this, right?

http://en.wikipedia.org/wiki/Adapter_pattern

Using what this link above suggests (adapter "has-a" or "is-a" adaptee) is
the better way to go, IMO. There are multiple ways to do this in Ruby.
Monkey-patching/open-classes makes the solution: adapter IS adaptee. I
don't know if you can even call it the adapter pattern since you are
destroying the adaptee interface.

On Feb 27, 2008, at 8:38 AM, Eric Mahurin wrote:

> On Wed, Feb 27, 2008 at 7:46 AM, James Gray
> <james@grayproductions.net>
> wrote:
>
>> On Feb 24, 2008, at 10:02 PM, James Gray wrote:
>>
>>> On Feb 23, 2008, at 4:23 PM, Eric Mahurin wrote:
>>>
>>>> I usually only do monkey patching in the
>>>> following cases which have no reuse: top-level script, testing, and
>>>> quick hacking.
>>>
>>> I think it's the ideal tool for adding compatibility methods.
>>
>> Along these lines, I read a chapter in Design Patterns in Ruby last
>> night that suggests using Ruby's open classes as one possible way to
>> implement the Adapter pattern. The book includes a pretty good
>> discussion of the plusses and minus to this approach and makes
>> recommendations about when it's probably worth the trade-off. It's a
>> good read.
>>
>> James Edward Gray II
>
>
> I don't have the book. I wouldn't mind seeing the +/- list.

I don't think I would do it much justice condensing it down for this
email, but it basically amounted to how well you know the code you are
adapting and how simple the changes are. The author felt it was
probably OK if you knew the class involved well and you were just
aliasing a method or two. Again though, I'm grossly simplifying here.

The book also talked about adding the methods needed to the singleton
class of individual objects. I thought that was an awesome twist that
we probably don't consider enough.

> You are talking about this, right?
>
> http://en.wikipedia.org/wiki/Adapter_pattern

Yes.

> I don't know if you can even call it the adapter pattern since you are
> destroying the adaptee interface.

I view it as a Ruby way to think about the problem. Don't they always
say that intent is the most important aspect to the design patterns?

James Edward Gray II

On Feb 27, 8:30 am, "Eivind Eklund" <eekl...@gmail.com> wrote:
> On Tue, Feb 26, 2008 at 7:25 PM, James Britt <james.br...@gmail.com> wrote:
> > Code that is poorly written or does not play well with others tends to
> > get discarded.
>
> We still have Gems, which don't play well at all with others (on a
> technical basis) - witness the conflicts with the Debian team, and
> what every other Unix package maintainer says about this. This proves
> that this mechanism doesn't work so well if there is a size/momentum
> advantage.

I would now suggest that it is the FHS that is holding us back, not
the other way around --talk about your size/momentum advantage.

Suggested reading:

http://gobolinux.org/index.php?page=...icles/clueless

> Also, discussing what is appropriate and not is a good way to educate
> people, and to us all learn to think more clearly in the area.

Very true.

T.

2008/2/26, Clifford Heath <no@spam.please.net>:
> Well, I can't find import-module-extended, but assuming it's like
> import-module... you're missing:

Clifford, thanks for listing your requirements.

> * performance

Comparable to other AOP frameworks in Ruby. That might be an obstacle
for you, but it's not for me yet.

> * isolation of instance variables that the extensions might create

If you are really serious about this, there are ways to achieve this goal.

> * ability for an extended class to *always* appear extended when
> called from anywhere in a class that knows about those extensions,
> without having to constantly remember to add the extensions on each
> call.

Please look at my sample code again. It does exactly what you describe.

> Is that enough to claim "no sensible way" of doing it?

Not for me, as I said above. But since there's no formal definition of
"sensible ways", there might be no sensible way for you. Maybe we
should take this to another thread or to private mail if you want to
discuss it further.

Regards,
Pit

On 2/27/08, Trans <transfire@gmail.com> wrote:
>
>
> On Feb 27, 8:30 am, "Eivind Eklund" <eekl...@gmail.com> wrote:
>
> > On Tue, Feb 26, 2008 at 7:25 PM, James Britt <james.br...@gmail.com> wrote:
> > > Code that is poorly written or does not play well with others tends to
> > > get discarded.
> >
> > We still have Gems, which don't play well at all with others (on a
> > technical basis) - witness the conflicts with the Debian team, and
> > what every other Unix package maintainer says about this. This proves
> > that this mechanism doesn't work so well if there is a size/momentum
> > advantage.
>
>
> I would now suggest that it is the FHS that is holding us back, not
> the other way around --talk about your size/momentum advantage.
>
> Suggested reading:
>
> http://gobolinux.org/index.php?page=...icles/clueless
>
>
> > Also, discussing what is appropriate and not is a good way to educate
> > people, and to us all learn to think more clearly in the area.

In the case of Debian and Gems, I think it's a mixture of a somewhat
draconian interpretation of the FHS, and a desire to make the gems
themselves somehow work like debian packages, which don't envision
things like having multiple versions of a gem installed concurrently.

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

On Feb 27, 2008, at 6:20 AM, Jones, Brian - McClatchy Interactive wrote:

>> It may be enough to simply have ruby warn us when and where a class
>> has
> been re-opened and a means to ignore it by file/path or namespace if
> we
> want.

This whole thing is a complex philosophical discussion about the goals
of the language and the problems that could be encountered if...

Perhaps someone could, instead of debating the theory, the impacts on
scaling, and the philosophy, come up with a patch and run it by Ruby
core for comment. Otherwise this thread could continue forever with
those who find monkey patching useful saying ... um ... "I find monkey
patching useful" and those who have issues with open classes
saying ... um ... "it's not scalable, it's surprising, it's destroying
Ruby, etc."

The arguments are out there. What it takes is a stake in the ground (a
patch) that demonstrates some "better way" that doesn't cause Ruby to
break existing applications.

FWIW, I'm in the first camp, and feel Ruby does just fine for my
needs. I understand the arguments to the contrary, but don't
anticipate them being a problem in my application space. That's not to
claim validity of either position, just disclosure of my predisposition.

Cheers,

Steve

On Wed, Feb 27, 2008 at 1:44 PM, s.ross <cwdinfo@gmail.com> wrote:
> FWIW, I'm in the first camp, and feel Ruby does just fine for my
> needs. I understand the arguments to the contrary, but don't
> anticipate them being a problem in my application space. That's not to
> claim validity of either position, just disclosure of my predisposition.

If that's how you personally divide things, then I'm in your camp too.
No, really.

I'm actually not very interested in any of the proposals to extend
Ruby (either with patches or with Ruby code). I'll be completely
satisfied if, as a result of this discussion, a few more people think
"oh yeah, I could do this with [inheritance|mixins|delegation|etc.],
and it would be easier than monkey patching!" when they set out to add
some functionality to an existing class.

As far as the language goes, I'm happy with Ruby the way it is.

--
Avdi

On Wed, Feb 27, 2008 at 7:12 AM, Joel VanderWerf
<vjoel@path.berkeley.edu> wrote:
> Robert Dober wrote:
> > On Tue, Feb 26, 2008 at 4:52 PM, James Gray <james@grayproductions.net> wrote:
> >> On Feb 26, 2008, at 9:45 AM, Jones, Brian - McClatchy Interactive wrote:
> >>
> >> > I'd be at least a little interested in potentially offering developers
> >> > the chance to 'lock' their classes from monkey patches.
> >>
> >> There are probably ways around this, but:
> > Hmm I do not think that one can overrule freeze; I never found a way,
> > anyone else?
> > Cheers
> > Robert
>
> You can monkeypatch Class#freeze, as long as you get there first
>
> class Class
> def freeze; end
> end
>
> class Foo
> def bar; end
> end
>
> Foo.freeze
>
> class Foo
> def zap; end
> end
>
>
>
>
> --
> vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
>
>

That indeed is a truly perverse use case for MP, you have my deepest respect .
It is indeed an extreme example what the enabling approach can lead
to, but it is maybe not a coincidence that it was Smalltalk which
really brought up UT first IIRC?
That is something we should add into this discussion, MP might be a
danger for Ruby to be extincted (I do not believe so but just for the
sake of argument), TDD (or BDD) might save it somehow.
But there is no doubt it is not much of a relief if somebody released
something stupid in a library and now a zillion tests do not pass
anymore.

Just out of curiosity why does Class#freeze need to exist and cannot
be inherited from Object#freeze?

Cheers
Robert

--
http://ruby-smalltalk.blogspot.com/

---
Whereof one cannot speak, thereof one must be silent.
Ludwig Wittgenstein

Robert Dober wrote:
> Just out of curiosity why does Class#freeze need to exist and cannot
> be inherited from Object#freeze?

Because Module#freeze is defined by ruby (so redefining Object#freeze
would not have the desired effect in this case).

--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

On Wed, Feb 27, 2008 at 4:04 PM, Trans <transfire@gmail.com> wrote:
> On Feb 27, 8:30 am, "Eivind Eklund" <eekl...@gmail.com> wrote:
>
> > On Tue, Feb 26, 2008 at 7:25 PM, James Britt <james.br...@gmail.com> wrote:
> > > Code that is poorly written or does not play well with others tends to
> > > get discarded.
> >
> > We still have Gems, which don't play well at all with others (on a
> > technical basis) - witness the conflicts with the Debian team, and
> > what every other Unix package maintainer says about this. This proves
> > that this mechanism doesn't work so well if there is a size/momentum
> > advantage.
>
> I would now suggest that it is the FHS that is holding us back, not
> the other way around --talk about your size/momentum advantage.
>
> Suggested reading:
>
> http://gobolinux.org/index.php?page=...icles/clueless

I perfectly agree that a large part of the reason the FHS is the way
it is (and why we're using FHS or something similar on most Unix
systems) is historical momentum. I feel that's a tangent, though.

In my opinion, the core issue is that people should be able to expect
a single directory layout on a single operating system, so the
operating system owns the directory layout. If you are going to write
a package manager that works on different operating systems, it should
be able to adopt to the conventions of those operating systems, or it
hose the users of the operating systems. Users that don't care if a
package is written in Ruby, or in Python, or in C, or whatever.

I think having different operating systems - like GoboLinux, like Mac
OS X, like Windows - that experiment with different layouts is a good
thing. There may well be other layouts that work better than the
traditional one these days. I just think this is an area for
operating systems to experiment, not programming languages.

Eivind.

Hi,

I have read all other Statements in this thread, but as it is such a
vast collection of opinions, its hard to keep track. So: if I mention
something for the second time, please ignore it .

I think the problem with MonkeyPatching is clear: it is a hack and
hacks tend to die soon. I am strongly opposed to use it in an official
release without thinking twice. Usually, there is a better way to
solve the problem. When browsing Rails plugins (i don't want to bash
rails, but thats an incredibly big source third-party-libraries), I
often see gruesome hacks to solve problems that could easily be solved
otherwise - because the author obviously didn't know about the right
way. Some time ago, many plugins had some implementation of
String#constantize (better, worse, the same as the Rails version).
This shows one thing:
Plugin authors are not aware of everything the language has to offer.
So they do what they do best. Which is not always good. The other side
of the problem is that the target of your patch is not written to be
extended (have a look at the "render"-Method in rails) - so you only
quick resort is a hack.
Monkeypatching is cool - if you think well an at least twice about it.

The problems with meta-programming is another one:
We love it. We advertise it as core features of the language (which -
in my book - it is not).

Take the above example: Array#to_csv

Why not CSV.from(arg)? It is cumbersome to read and we need to think
about a way to split the implementation details of from(Array) and
from(otherType) in halves. But from an OO-perspective, it makes
perfect sense: an Array doesn't have to care about the types that it
can be converted into an it is well encapsulated.

But, because we are lazy, lazy ruby programmers, we love our
object.send syntax. So we implement a shorthand method. Another
example is Object.in?(), often seen as a shorthand for
some_collection.contains?(obj) (Im not sure, but this is called
'grief', afaik). The first is nicer, the second is cleaner. Many vote
for the first - another Method in Object. Another well known Library
defines Object#should because they think of it to be nicer. By doing
this, we are slowly overloading the core-system. I like approach of
facets: they are a collection of such idioms, but they must be
switched on explicitly.
The question you have to answer for yourself when creating such a
method is: "Is it really that important?". Often I have the impression
that this question is often answered with "Yeah, its cool and its the
ruby way!"

On the other hand, those features are the ones that make the little
difference. Used correctly, open classes are a way to beautiful and
well constructed code.

It all comes boils to a matter of knowledge, experience and
discipline. We have got to be aware that many ruby developers don't
have all of those.

Greetings
Florian Gilcher <Skade>

On Feb 28, 2008, at 8:16 AM, Florian Gilcher wrote:

> Some time ago, many plugins had some implementation of
> String#constantize (better, worse, the same as the Rails version).
> This shows one thing:
> Plugin authors are not aware of everything the language has to offer.

Just to be clear, the Ruby programming "language" does not have a
method called String#constantize. It's provided by the Ruby on Rails
"framework."

James Edward Gray II

Yes,

sorry for not mentioning. I just found that many that where developing
plugins for Rails where patching things that didn't need to be patched
or hacked in the Framework.
Thanks for the clarification.

Florian Gilcher

On Feb 28, 2008, at 3:36 PM, James Gray wrote:

> On Feb 28, 2008, at 8:16 AM, Florian Gilcher wrote:
>
>> Some time ago, many plugins had some implementation of
>> String#constantize (better, worse, the same as the Rails version).
>> This shows one thing:
>> Plugin authors are not aware of everything the language has to offer.
>
> Just to be clear, the Ruby programming "language" does not have a
> method called String#constantize. It's provided by the Ruby on
> Rails "framework."
>
> James Edward Gray II
>
>

That's what the poster said: "better, worse, the same as the Rails version".

On 2/28/08, James Gray <james@grayproductions.net> wrote:
> On Feb 28, 2008, at 8:16 AM, Florian Gilcher wrote:
>
> > Some time ago, many plugins had some implementation of
> > String#constantize (better, worse, the same as the Rails version).
> > This shows one thing:
> > Plugin authors are not aware of everything the language has to offer.
>
> Just to be clear, the Ruby programming "language" does not have a
> method called String#constantize. It's provided by the Ruby on Rails
> "framework."
>
> James Edward Gray II
>
>
>


--
Avdi

Please don't top post.

On 2/28/08, James Gray <james@grayproductions.net> wrote:

> On Feb 28, 2008, at 8:16 AM, Florian Gilcher wrote:
>
>> Some time ago, many plugins had some implementation of
>> String#constantize (better, worse, the same as the Rails version).
>> This shows one thing:
>> Plugin authors are not aware of everything the language has to offer.
>
> Just to be clear, the Ruby programming "language" does not have a
> method called String#constantize. It's provided by the Ruby on Rails
> "framework."

>
> On Feb 28, 2008, at 8:50 AM, avdi@avdi.org wrote:
>
>> That's what the poster said: "better, worse, the same as the Rails
>> version".

Please reread the quote above where the poster hints that the method
is provided by a "language."

James Edward Gray II

On Thu, Feb 28, 2008 at 10:07 AM, James Gray <james@grayproductions.net> wrote:
> Please don't top post.

Sorry, that was posted from the GMail mobile interface.

--
Avdi

On Feb 28, 2008, at 4:07 PM, James Gray wrote:

> Please don't top post.
>
> On 2/28/08, James Gray <james@grayproductions.net> wrote:
>
>> On Feb 28, 2008, at 8:16 AM, Florian Gilcher wrote:
>>
>>> Some time ago, many plugins had some implementation of
>>> String#constantize (better, worse, the same as the Rails version).
>>> This shows one thing:
>>> Plugin authors are not aware of everything the language has to
>>> offer.
>>
>> Just to be clear, the Ruby programming "language" does not have a
>> method called String#constantize. It's provided by the Ruby on Rails
>> "framework."
>
>>
>> On Feb 28, 2008, at 8:50 AM, avdi@avdi.org wrote:
>>
>>> That's what the poster said: "better, worse, the same as the Rails
>>> version".
>
> Please reread the quote above where the poster hints that the method
> is provided by a "language."
>
> James Edward Gray II
>

As i said, it was an accidential error and should read "Framework".
Programming Ruby for 5 years, I know the distinction .

Florian Gilcher

On Thu, Feb 28, 2008 at 6:51 AM, Joel VanderWerf
<vjoel@path.berkeley.edu> wrote:
> Robert Dober wrote:
> > Just out of curiosity why does Class#freeze need to exist and cannot
> > be inherited from Object#freeze?
>
> Because Module#freeze is defined by ruby (so redefining Object#freeze
> would not have the desired effect in this case).
I was not criticizing your solution(1), I only wanted to know something.

Let me rephrase my question then, why Module#freeze what has it to do
in addition to Object#freeze
Just in case you happen to know.
Thx in advance

Cheers
Robert

>
> --
>
>
> vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
>
>



--
http://ruby-smalltalk.blogspot.com/

---
Whereof one cannot speak, thereof one must be silent.
Ludwig Wittgenstein

On Thu, Feb 28, 2008 at 6:16 AM, Florian Gilcher <flo@andersground.net> wrote:
>
> But, because we are lazy, lazy ruby programmers, we love our
> object.send syntax. So we implement a shorthand method. Another
> example is Object.in?(), often seen as a shorthand for
> some_collection.contains?(obj) (Im not sure, but this is called
> 'grief', afaik). The first is nicer, the second is cleaner. Many vote
> for the first - another Method in Object. Another well known Library
> defines Object#should because they think of it to be nicer. By doing
> this, we are slowly overloading the core-system.

And? There's nothing wrong with "overloading the core system" if the
end result is cleaner and more readable code. Personally, good ruby
code is all about expressiveness and readability, not proper OO
encapsulation and staying-out-of-the-core. The only real problem, as
you note, is that of conflicting extensions to the same core classes,
and care does need to be taken with that, but that's no reason to
throw the baby out with the bathwater.

One interesting thing to do is something I've seen in the Javascript
world - libraries that come with an option to install themselves in
core classes or stick to a namespace, so that you can either type
MyLib.do_something(object), or turn the option on and then do
object.do_something.

martin

On Feb 24, 4:43 pm, Gary Wright <gwtm...@mac.com> wrote:

> Facets defines Hash#- based on [key,value] pairs and not keys. An
> argument can be made for either approach but you can't integrate code
> bases that have different expectations for Hash#-.

BTW, there is a reason for that. You can do:

ahash - otherhash.keys

T.