warning: undefining `object_id' may cause serious problems

[wlipa]

In Ruby 1.9.3 / Rails 3.2.8, including the blankslate gem indirectly as a jbuilder dependence causes the following warning at server startup:

.gem/ruby/1.9.1/gems/blankslate-3.1.2/lib/blankslate.rb:51: warning: undefining `object_id' may cause serious problems

[adammeghji]

+1

[xxx]

+1, though the repo where the gem is built from seems to be elsewhere - it's not this one.

[motioneleven]

+1

[madmed88]

+1

[ramaman]

+1

[galetahub]

+1

[ichernev]

+1

[radkodinev]

+1

[edzhelyov]

+1

[alexbhr]

+1 on fixing this

[bbatsov]

+1

[kenn]

+1 but yeah, the source code here is different than the gem. what's the current status of maintenance / ownership?

[brandoniscool]

+1

[trcarden]

+1

[gitkvn]

+1

[waratuman]

+1

[peterjm]

+1

[jdjkelly]

+2

[fenelon]

+3

[shannonwells]

+1 The problem does exist in this source tree.

[wlipa]

It looks like this is going to be fixed in jbuilder by avoiding the dependency on blankslate.
rails/jbuilder#59

[9mm]

+1

[ghost]

+1

[kenneth]

+1

[xxx]

The current release of jbuilder no longer has a dependency on blankslate.

[SixArm]

+1

[Kjuly]

+1

[ranmocy]

That works.

Hope the maintainer can pull this and release new version, but this is not updated for 7 months.

[kdurski]

@ranmocy - it works of course but to be honest I am not sure whether its a correct fix after some thinking. Rather then adding object_id to exception list, it might have been better solution to temporarily change warn level. Guess it depends on the context ;)

[ranmocy]

@kdurski I can't imagine that someone would like to hide object_id method. As the warning saying, that will cause uncertain severe issue.

But anyway, I just hack my local gem file to prevent warning when I use irb.
I won't apply it to production environment without community full tests ;)

[kdurski]

@ranmocy As I said it depends on context - jBuilder was one of the gems that used blankslate. Honestly I don't know that gem nor what it does but it dropped that dependency. But for me issue was in rubypython gem, a gateway to python from within ruby. There you can imagine that object_id might not be necessary to have ;)

[ranmocy]

@kdurski (^。^) Same gem for me~ For Jekyll~

Yes, it is better to remove the warning directly. But is it possible to change, not hack, the warning level?

As you said, it is dispensable as to python. So simply ignoring it will be fine without conflict though remain a useless method. At the same time, removing the method is quite not well to other gems. Maybe that's why jBuilder dropped it.
So I guess, your hack should be quite well in most cases.

After all, I just hate the annoying warnings all over my output ;)

[kdurski]

@ranmocy Keep in mind that blankslate does not affect other gems. If it did, it would break your whole app completely as object_id warning was only added in 1.9.3 - before that it was still undefined, only didn't output warning.

The whole idea with this gem is that it creates new class (Blankslate) that does not inherit almost anything from ruby build-in Object. Therfore it might be better to change warn level:

v, $VERBOSE = $VERBOSE, nil
# ....
$VERBOSE = v

Will probably update the pull request later on :)

[burgua]

+1

[ranmocy]

@kdurski This commit got a syntax error, since the line before it is end with and.
The original line is a part of the if conditions, and the warning is not throwed by name !~ /^(__|instance_eval)/ but undef_method name.
So I guess you may need to wrap it outside the whole if statement.

[kdurski]

@ranmocy You are 100% correct :) To be honest I forgot about this pull request, since I started keeping gem in vendor/gems and fixed it after. Gonna cancel it in a sec, thx for reminder!

[diegocharles]

+1

[noctivityinc]

+1 here on this as well. Any update?

[pboling]

Seriously though. Wat? 👍

[stuartchaney]

+1

[stuartchaney]

Best route of action is to fork IMO
:-(

[masover]

Actually, not a bad idea. Sorry, I don't plan to maintain this anymore even at this level, for two reasons:

First: Someone else controls the rubygems.org project. According to the README, that's Jack Danger, over at https://github.com/JackDanger/blankslate. I'd try to take that over, but...

Second, I never run Ruby 1.8 anymore. JRuby is on 1.9.3-compatibility by default and supports 2.0, and Rubinius is on 2.1-compatibility. Ruby Enterprise Edition's entire reason for existence was to add a COW-friendly garbage collector, and MRI can do that these days. I suppose I'd be leaving out Maglev and maybe IronRuby, but I'm perfectly comfortable just using BasicObject, even in library code.

So even if I'm going to publish other gems, I wouldn't bother testing with 1.8, so I haven no reason to keep it around, and no motivation to maintain this library. As far as I'm concerned, it's obsolete, just use BasicObject.

If you really do have a good reason to support 1.8, by all means, fork it!

[noctivityinc]

@masover - thanks for the note but why do you think this is a 1.8 Ruby issue?

/Users/jlippiner/.rvm/gems/ruby-2.0.0-p247@wecora/gems/blankslate-3.1.2/lib/blankslate.rb:51

As you can see, this is clearly happening in ruby 2.0 right now. Am I missing something?

[pboling]

What @masover is saying is use the BasicObject class from Ruby Standard Library instead of this gem.

That is, of course, ideal.

The only problem with that is that this gem is a dependency of other gems.

[masover]

Correct on both counts. Just use BasicObject, but something should be done about existing dependencies...

So, basically, yes, if you use a Ruby that's newer than 1.8, you should use BasicObject.

If you maintain a library that depends on BlankSlate, but you don't support Ruby 1.8, just swap it for BasicObject and remove the dependency. If you can't -- if you're using other libraries that depend on BasicObject -- please file a bug with them, even if you're going to work around it.

If you use Builder, you should remove the BasicObject dependency and use Builder::BlankSlate, which resolves this issue quite neatly (and avoids having two copies of BlankSlate). Unfortunately, I don't see any development on Builder since a year ago, so maybe it's not maintained either.

If you maintain a library that depends on BlankSlate, and you really want to support Ruby 1.8, you should do what Builder does -- here's how I'd do it:

module Yourlibrary
  unless defined? ::BasicObject
    require 'blankslate'
    BasicObject = BlankSlate
  end
end

...and then write the rest of your code to BasicObject for modern versions of Ruby, and use BlankSlate as a polyfill.

That could easily be patched into the library itself, but like I said, I don't control the Rubygems project. Also, maybe it'd break something anyway, maybe there's subtle differences between BlankSlate and BasicObject that someone is relying on.

[noctivityinc]

Exactly. +1 again

On Jun 12, 2014, at 3:04 AM, Peter Boling notifications@github.com wrote:

What he is saying is use the BasicObject class from Ruby Standard Library instead of this gem.

That is, of course, ideal.

The only problem with that is that this gem is a dependency of other gems.

—
Reply to this email directly or view it on GitHub.