This project is archived and is in readonly mode.
XML Builder redefines some methods that breaks things
Reported by mt | August 26th, 2008 @ 11:01 PM | in 2.x
I have been doing some stuff with the XML Builder, and running into problems whenever I try to debug it with an IDE (trying both Eclipse and Netbeans). I believe the problem is that the Builder classes remove all the default instance methods from their objects, including such basics as .class and .inspect, which breaks the debugger. It does this by means of the BlankSlate class, which is also used elsewhere in Rails.
I patched Builder to not inherit from BlankSlate, which fixes my problems but means I can't generate XML tags with common method names. That's OK, but not a great fix. I wondered if anybody else has encountered this problem and has a better solution. I've heard that 1.9 changes this in some way.
Oh, and the equality checking methods are also gone! So if you have an xml builder object, you can't do equality checks on it because that will insert <==> tags into your generated XML. Not good.
This bug does not just break IDEs, but it was affecting my code in ways that I can't explain. Weird stuff was happening and stopped when I took BlankSlate out of the picture.
To explain what I mean:
$ script/console Loading development environment (Rails 2.1.0)
xml = Builder::XmlMarkup.new(:indent => 1) => xml == nil
=> "\n<==></==>\n"
Yech.
Comments and changes to this ticket
-
Jeremy Kemper August 27th, 2008 @ 12:50 AM
- State changed from “new” to “invalid”
This feels strange, but it's expected behavior. Contact your IDE vendor with a bug report if its inspector or debugger can't handle these objects.
-
mt August 27th, 2008 @ 05:49 AM
It can't possibly be valid behavior for an equality operator to cause side effects.
Note that this did not just break the IDE, it broke the application itself.
-
Jeremy Kemper August 27th, 2008 @ 05:54 AM
It can, however, be valid behavior for the absence of an equality operator to confuse and frustrate you ;)
-
mt August 27th, 2008 @ 06:08 AM
How much sense does it make to sacrifice very basic semantics of objects for the ability to generate a <==> tag, something which nobody will ever want to do?
Oh well, I already patched this so our application can run, so I don't care to debate it further, but this bug wasted a good deal of time of me and my coworkers, and I thought I would try to spare others.
-
Jeremy Kemper August 27th, 2008 @ 06:40 AM
I agree it's a strange thing to run into. But it's reasonable and, once you consider the design constraints at play, even desirable.
If you think BlankSlate has minimal semantics, wait until you see BasicObject in Ruby 1.9! Both are intended to remove most of the conveniences of Object, but BasicObject goes even further than BlankSlate. Even things like constant resolution fail.
These 'minimal' objects play an interesting role in Ruby. You'll see the pattern elsewhere with objects whose method calls act as proxies in some way. Looking at this pattern as sacrificing something just to generate some crazy (and invalid) xml tag is missing the larger picture of their design and role in Ruby.
I suggest you continue the discussion on the ruby-talk mailing list :)
-
mt August 27th, 2008 @ 07:01 PM
FWIW, I notice that BasicObject in Ruby 1.9 DOES define == properly. Nyah.
-
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
<h2 style="font-size: 14px">Tickets have moved to Github</h2>
The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>
Jeremy Kemper
mt