Forum: RSpec Missing method implementation_backtrace

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Ben F. (Guest)
on 2008-11-20 20:52
(Received via mailing list)
We just upgraded from rspec version 1.1.4 to rspec version 1.1.11 and
found
that this no longer exists:






# File lib/spec/example/example_methods.rb, line 84
      def implementation_backtrace
        eval("caller", @_implementation)
      end



I don't really know what this method is for and don't really care that
it is
gone; however, Netbeans 6.5 does care that it is gone and is not able to
run
tests without it.  As a temporary band-aid I have added the method back
locally.  I was wondering if someone could enlighten me as to why the
method
was removed?



Thanks!





Ben F.
David C. (Guest)
on 2008-11-20 21:35
(Received via mailing list)
On Thu, Nov 20, 2008 at 12:44 PM, Ben F.
<removed_email_address@domain.invalid> wrote:
>
>       end
>
>
>
> I don't really know what this method is for and don't really care that it is
> gone; however, Netbeans 6.5 does care that it is gone and is not able to run
> tests without it.  As a temporary band-aid I have added the method back
> locally.  I was wondering if someone could enlighten me as to why the method
> was removed?

Unfortunately we don't yet have a formal API for tool vendors to use,
so NetBeans apparently used a method that we view as internal and it
got moved or renamed during a refactoring.

This is something we plan to address over the coming months:
formalizing an API for extension and tool use.

FWIW,
David
Scott T. (Guest)
on 2008-11-20 21:37
(Received via mailing list)
On Nov 20, 2008, at 2:35 PM, David C. wrote:

>>      def implementation_backtrace
>> able to run
> This is something we plan to address over the coming months:
> formalizing an API for extension and tool use.
>

Also, check out this:

http://metaclass.org/2008/6/7/calling-in-the-dark

Scott
rubyphunk (Guest)
on 2008-11-21 01:48
(Received via mailing list)
Hi,

same problem here. I always used "example.implementation_backtrace" in
a custom formatter to find out to which spec file a passing example
belongs to.
Is there another way to get the file path?


lg // andreas
David C. (Guest)
on 2008-11-21 20:00
(Received via mailing list)
On Thu, Nov 20, 2008 at 5:47 PM, rubyphunk 
<removed_email_address@domain.invalid>
wrote:
> Hi,
>
> same problem here. I always used "example.implementation_backtrace" in
> a custom formatter to find out to which spec file a passing example
> belongs to.
> Is there another way to get the file path?

Looking through the code I see the name was changed to
example_backtrace, and I can see why it was changed to that. In fact,
looking closer I really think it should just be backtrace.

I'm going to change it to #backtrace, rdoc it up to formalize its
place in the world as an API method, and, in the interest of playing
nice w/ NetBeans, reinstate a deprecated implementation_backtrace that
delegates to backtrace.

Rubyphunk, what you can do in the short run is alias
implementation_backtrace, example_backtrace, but you'll have to change
that for the next release. Sorry about the churn, but this was really
not a formally public method to begin with. Now we will make it so.

Cheers,
David
David C. (Guest)
on 2008-11-21 22:25
(Received via mailing list)
On Thu, Nov 20, 2008 at 9:20 PM, David C. <removed_email_address@domain.invalid>
wrote:
> looking closer I really think it should just be backtrace.
>
> I'm going to change it to #backtrace, rdoc it up to formalize its
> place in the world as an API method, and, in the interest of playing
> nice w/ NetBeans, reinstate a deprecated implementation_backtrace that
> delegates to backtrace.
>
> Rubyphunk, what you can do in the short run is alias
> implementation_backtrace, example_backtrace, but you'll have to change
> that for the next release. Sorry about the churn, but this was really
> not a formally public method to begin with. Now we will make it so.

Actually - I see that this change from implementation_backtrace to
example_backtrace was after the 1.1.11 release (the OP said this was
upgrading to 1.1.11, but it must have been upgrading to the current
code in git).

I'm still going to go ahead w/ this plan (rename to backtrace and
reinstate a deprecated implementation_backtrace before the next
release), but I just want to alleviate concern of anybody who might be
concerned that the current release doesn't play nice w/ NetBeans (at
least for this reason)

Cheers,
David
aslak hellesoy (Guest)
on 2008-11-23 01:23
(Received via mailing list)
On Fri, Nov 21, 2008 at 4:20 AM, David C.
<removed_email_address@domain.invalid>wrote:

> example_backtrace, and I can see why it was changed to that. In fact,
> not a formally public method to begin with. Now we will make it so.
>

How will people know that a method is part of an API? Can we simply say
that
if it has RDoc it's part of the API and stable, and if it doesn't it's
not?
(We can still RDoc non-API code, just put :nodoc: on it so it doesn't
get
part of the API docs).

WDYT?

Aslak
Peter J. (Guest)
on 2008-11-24 11:51
(Received via mailing list)
On Fri, Nov 21, 2008 at 8:28 AM, aslak hellesoy
<removed_email_address@domain.invalid> wrote:
>
> How will people know that a method is part of an API? Can we simply say that
> if it has RDoc it's part of the API and stable, and if it doesn't it's not?
> (We can still RDoc non-API code, just put :nodoc: on it so it doesn't get
> part of the API docs).

I think that would clarify the API *and* make the RDoc easier to read.
:)

Peter
David C. (Guest)
on 2008-11-24 14:01
(Received via mailing list)
On Fri, Nov 21, 2008 at 7:28 AM, aslak hellesoy
<removed_email_address@domain.invalid> wrote:
>> > a custom formatter to find out to which spec file a passing example
>> delegates to backtrace.
>
> WDYT?

I think that's where we want to land. It's going to take a bit of a
going through to get there though. I think that should be part of a
1.2 release (not necessarily the very next release) - that we put a
line in the sand as far as that is concerned.

Another thing to consider is what the Merb team has done, where public
methods are marked with ":api: public" in the RDoc. In fact, they've
done a good job of RDoco in general, with Parameters, Returns and
Notes consistently separated.

WDYTAT?
Andreas W. (Guest)
on 2008-11-24 17:56
(Received via mailing list)
On Fri, Nov 21, 2008 at 2:28 PM, aslak hellesoy
<removed_email_address@domain.invalid> wrote:

> How will people know that a method is part of an API? Can we simply say that
> if it has RDoc it's part of the API and stable, and if it doesn't it's not?
> (We can still RDoc non-API code, just put :nodoc: on it so it doesn't get
> part of the API docs).
>
> WDYT?
>
> Aslak

Wouldn't it be better to have a kind of standalone api. An interface
where the internal implementation can be changed but the public one
stays (mostly) consistent over different releases? IMO going this way,
the rspec-development would be more aware of changes to that API.

lg // andreas
Andreas W. (Guest)
on 2008-11-24 17:59
(Received via mailing list)
On Fri, Nov 21, 2008 at 2:28 PM, aslak hellesoy
<removed_email_address@domain.invalid> wrote:

> How will people know that a method is part of an API? Can we simply say that
> if it has RDoc it's part of the API and stable, and if it doesn't it's not?
> (We can still RDoc non-API code, just put :nodoc: on it so it doesn't get
> part of the API docs).
>
> WDYT?

Wouldn't it be better to have a kind of standalone api. An interface
where the internal implementation can be changed but the public one
stays (mostly) consistent over different releases? IMO going this way,
the rspec-development would be more aware of changes to that API.

lg // andreas
David C. (Guest)
on 2008-11-24 18:00
(Received via mailing list)
On Sun, Nov 23, 2008 at 5:16 AM, David C. <removed_email_address@domain.invalid>
wrote:
>>> >
>>> place in the world as an API method, and, in the interest of playing
>> (We can still RDoc non-API code, just put :nodoc: on it so it doesn't get
> methods are marked with ":api: public" in the RDoc. In fact, they've
> done a good job of RDoco in general, with Parameters, Returns and
> Notes consistently separated.
>
> WDYTAT?

PS - I did add rdoc for the #backtrace methods in both
ExampleGroupMethods and ExampleMethods, as well as their deprecated
counterparts.
David C. (Guest)
on 2008-11-24 18:05
(Received via mailing list)
On Fri, Nov 21, 2008 at 4:50 PM, Andreas W. 
<removed_email_address@domain.invalid>
wrote:
>> Aslak
>
> Wouldn't it be better to have a kind of standalone api. An interface
> where the internal implementation can be changed but the public one
> stays (mostly) consistent over different releases? IMO going this way,
> the rspec-development would be more aware of changes to that API.
>
> lg // andreas

Can you elaborate? What would make an api "standalone" in this context?
aslak hellesoy (Guest)
on 2008-11-24 18:25
(Received via mailing list)
On Sun, Nov 23, 2008 at 12:16 PM, David C.
<removed_email_address@domain.invalid>wrote:

> >> >
> >> place in the world as an API method, and, in the interest of playing
> > if it has RDoc it's part of the API and stable, and if it doesn't it's
>
> Another thing to consider is what the Merb team has done, where public
> methods are marked with ":api: public" in the RDoc. In fact, they've
> done a good job of RDoco in general, with Parameters, Returns and
> Notes consistently separated.
>
> WDYTAT?
>

I like that
This topic is locked and can not be replied to.