warning: undefining `object_id' may cause serious problems #7

Open
wlipa opened this Issue Sep 11, 2012 · 46 comments

Comments

Projects
None yet

wlipa commented Sep 11, 2012

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

xxx commented Sep 14, 2012

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

@ghost

ghost commented Sep 15, 2012

+1

+1

ramaman commented Sep 16, 2012

+1

+1

+1

+1

alexbhr commented Sep 17, 2012

+1 on fixing this

bbatsov commented Sep 17, 2012

+1

kenn commented Sep 17, 2012

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

+1

gitkvn commented Sep 18, 2012

+1

+1

peterjm commented Sep 18, 2012

+1

+2

fenelon commented Sep 18, 2012

+3

+1 The problem does exist in this source tree.

wlipa commented Sep 18, 2012

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

9mm commented Sep 26, 2012

+1

erwin16 commented Oct 17, 2012

+1

kenneth commented Nov 5, 2012

+1

xxx commented Nov 5, 2012

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

@ghost

ghost commented Nov 9, 2012

+1

Kjuly commented Nov 11, 2012

+1

ranmocy commented Nov 27, 2012

That works.

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

kdurski commented Nov 27, 2012

@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 commented Nov 27, 2012

@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 commented Nov 27, 2012

@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 commented Nov 27, 2012

@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 commented Nov 27, 2012

@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 commented Feb 26, 2013

+1

ranmocy commented Feb 26, 2013

@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 commented Feb 26, 2013

@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!

+1 here on this as well. Any update?

pboling commented Apr 8, 2014

Seriously though. Wat? 👍

Best route of action is to fork IMO
:-(

Owner

masover commented Jun 7, 2014

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!

@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 commented Jun 12, 2014

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.

Owner

masover commented Jun 12, 2014

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.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment