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.
On Thu, Nov 20, 2008 at 12:44 PM, Ben F.
[email protected] 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
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
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
On Thu, Nov 20, 2008 at 9:20 PM, David C. [email protected]
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
On Fri, Nov 21, 2008 at 4:20 AM, David C.
[email protected]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
On Thu, Nov 20, 2008 at 5:47 PM, rubyphunk [email protected]
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
On Fri, Nov 21, 2008 at 8:28 AM, aslak hellesoy
[email protected] 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
On Fri, Nov 21, 2008 at 7:28 AM, aslak hellesoy
[email protected] 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?
On Fri, Nov 21, 2008 at 2:28 PM, aslak hellesoy
[email protected] 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
On Fri, Nov 21, 2008 at 2:28 PM, aslak hellesoy
[email protected] 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
On Sun, Nov 23, 2008 at 5:16 AM, David C. [email protected]
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.
On Fri, Nov 21, 2008 at 4:50 PM, Andreas W. [email protected]
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?
On Sun, Nov 23, 2008 at 12:16 PM, David C.
[email protected]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