Exemplary way to show a list is sorted?

#1

RSpeckers:

I’m asserting that a list should be sorted by affinity. The following
code is good enough for government work, but is there some more clever
way to show that each element is equal or less than the previous
element?

it ‘should rank posts by affinity’ do
list = @map.sort_frobs_by_affinity

list[1].affinity.should >= list[1].affinity
list[2].affinity.should >= list[2].affinity
list[3].affinity.should >= list[3].affinity
list[4].affinity.should >= list[4].affinity

end

Notice I could just write…

list.map(&:affinity) == list.map(&:affinity)

…but it seems that the point of BDD is to make the business logic
obvious, not obscured in programming details, right?

–
Phlip
http://www.oreilly.com/catalog/9780596510657/
^ assert_xpath
http://tinyurl.com/yrc77g <-- assert_latest Model

#2

On Sun, Feb 8, 2009 at 5:48 PM, Phlip removed_email_address@domain.invalid wrote:

RSpeckers:

I’m asserting that a list should be sorted by affinity. The following

In BDD we say “expecting” instead of “asserting”

code is good enough for government work, but is there some more clever
way to show that each element is equal or less than the previous
element?

it ‘should rank posts by affinity’ do
list = @map.sort_frobs_by_affinity

list[1].affinity.should >= list[1].affinity

please use “should be >=” as “should >=” will eventually be deprecated
and removed.

obvious, not obscured in programming details, right?
Right. I’ve done stuff like this before:

[b,d,a,c].sort_with_special_method.should == [a,b,c,d]

Any other patterns out there?

David

#3

On Tue, Feb 10, 2009 at 12:19 PM, David C. removed_email_address@domain.invalid
wrote:

Right. I’ve done stuff like this before:

[b,d,a,c].sort_with_special_method.should == [a,b,c,d]

Any other patterns out there?

That’s how I do it.

Pat

#4

David C. wrote:

please use “should be >=” as “should >=” will eventually be deprecated
and removed.

Removed? You are not seriously contemplating forcing people to go back
and rewrite formally working specifications simply to tidy up the syntax
are you?

#5

On Tue, Feb 10, 2009 at 6:22 PM, James B. removed_email_address@domain.invalid
wrote:

David C. wrote:

please use “should be >=” as “should >=” will eventually be deprecated
and removed.

Removed? You are not seriously contemplating forcing people to go back
and rewrite formally working specifications simply to tidy up the syntax
are you?

Forcing people, eh? You don’t have to upgrade when that release is
made. No one is holding a gun to your head. You can always choose to
progress with the library, as it continues to evolve into new and
better ways of doing things.

Given the “should >=” to “should be >=” transition, I’m sure you can
safely do a find and replace in merely a few seconds if you bust out a
little regexp-fu, or maybe a few minutes if you do separate searches
for each operator.

If the idea of change is that abrasive to you, go to github, and feel
free to fork it yourself. After all, the jamesbyrne-rspec library is
only a few minutes away,

–
Zach D.
http://www.continuousthinking.com
http://www.mutuallyhuman.com

#6

Zach D. wrote:

On Tue, Feb 10, 2009 at 6:22 PM, James B. removed_email_address@domain.invalid
wrote:

David C. wrote:

please use “should be >=” as “should >=” will eventually be deprecated
and removed.

Removed? You are not seriously contemplating forcing people to go back
and rewrite formally working specifications simply to tidy up the syntax
are you?

Forcing people, eh? You don’t have to upgrade when that release is
made. No one is holding a gun to your head. You can always choose to
progress with the library, as it continues to evolve into new and
better ways of doing things.

There are enterprises in which the stability of development tools and
the confidence that one will not be forced to redo work already
completed is considered somewhat important, whatever your own situation
might be. Likewise, assuming the costs of maintaining a customized
variant of a general tool or foregoing future improvements in same to
maintain the value of existing work is not a choice savoured by many
firms that I can bring to mind, even if yours might be exceptional in
this regard. At issue is something commonly referred to as
cost/benefit, which ultimately turns into profit and loss.

I simply fail to see why evolving a tool in “better ways” necessarily
requires that the formerly “better” but now depreciated method be
removed. Such action causes avoidable and pointless work. I consider my
observation to be both reasonable and pertinent.

#7

On Tue, Feb 10, 2009 at 9:09 PM, James B. removed_email_address@domain.invalid
wrote:

Removed? You are not seriously contemplating forcing people to go back
completed is considered somewhat important, whatever your own situation
observation to be both reasonable and pertinent.
Keeping dead weight around has a cost as well, and has to be balanced
against the concerns you raise. As RSpec’s lead maintainer, I reserve
the right to introduce well documented but
backwards-compatibility-breaking-changes in major releases (i.e. 2.x,
3.x, etc) if I think it’s better for RSpec in the long run. This
change would be formally deprecated in a 1.x release and not removed
before the 2.0 release. I think you’ll find that other libraries in
our space (ruby/OSS) operate under the same principles.

General operating principles aside, we can certainly have a
conversation about the relative merits and cost/benefits of this
change. For me, the fact that we can say “should >=” in RSpec is
unfortunate. It is ugly, and should not exist. It is also duplication
of code elsewhere in the system, which has its own cost, so this is
not only about tidying up syntax. It’s about paying down technical
debt. It’s about lowering the barrier of entry to contribution so more
people play along.

I don’t want to make a bigger deal out of this than it is, but it
seems like we’re already passed that point.

FWIW,
David

#8

On Tue, Feb 10, 2009 at 10:09 PM, James B. removed_email_address@domain.invalid
wrote:

Removed? You are not seriously contemplating forcing people to go back
completed is considered somewhat important, whatever your own situation
might be. Likewise, assuming the costs of maintaining a customized
variant of a general tool or foregoing future improvements in same to
maintain the value of existing work is not a choice savoured by many
firms that I can bring to mind, even if yours might be exceptional in
this regard. At issue is something commonly referred to as
cost/benefit, which ultimately turns into profit and loss.

I simply fail to see why evolving a tool in “better ways” necessarily
requires that the formerly “better” but now depreciated method be
removed.

Just like there is cost associated with you taking time to update your
software to work with changes in the libraries and tools you use,
there is cost that the developers and maintainers of those very
libraries and tools will incur in order to maintain backwards
compatibility for features that are no longer deemed necessary.

This will lead to large negative effects over time, like a snowball
rolling down a hill. When the snow is good for packing though–none of
that fluffy stuff that doesn’t stick.

Such action causes avoidable and pointless work.

And to disprove this argument I will defer to the avoidable and
pointless work you will be causing those who maintain the software,

I consider my
observation to be both reasonable and pertinent.

Posted via http://www.ruby-forum.com/.

rspec-users mailing list
removed_email_address@domain.invalid
http://rubyforge.org/mailman/listinfo/rspec-users

–
Zach D.
http://www.continuousthinking.com
http://www.mutuallyhuman.com

#9

Zach D. wrote:

Such action causes avoidable and pointless work.

And to disprove this argument I will defer to the avoidable and
pointless work you will be causing those who maintain the software,

This is a completely illogical, and inherently contradictory, statement.

The issue is that a tool is supposed to be reliable. Reliability
includes the notion of preserving prior behaviour. This ensures that
people who invest their time in using the tool do not have their trust
in it destroyed by avoidable changes.

Further, by its very nature, a tool is used by vastly more people than
those that create the tool, otherwise it has little value. The idea
that a large number of people should be inconvenienced in order that a
few people are not strikes me as rather selfish and frankly,
unprofessional. Have you ever dared to make that type of argument to
your employer or client?

Yes, software evolves; and yes, there are many things we do in ignorance
that experience reveals as both unfortunate and wasteful. But, time is
money and causing test suites to fail by removing parts of the API just
because they appear ugly seems to me to break the contract that one
makes with those who choose to use your tool instead of another.

Let use consider this construct:

object.should be_close(value,delta)

why not

object.should be_close_to(value,delta)

Or

object.should be_near(value,delta)

Or

object.should approximate(value,delta) instead?

Which is “better” then the others? Which is “uglier”? Who cares? Pick
one and stick with it; or, if one feels compelled to improve the style
then at least keep that which already works, and is in use, working.

#10

On Wed, Feb 11, 2009 at 8:52 AM, James B. removed_email_address@domain.invalid
wrote:

your employer or client?

object.should approximate(value,delta) instead?

Which is “better” then the others? Which is “uglier”? Who cares? Pick
one and stick with it; or, if one feels compelled to improve the style
then at least keep that which already works, and is in use, working.

James,

Chill, please! This is not productive at all. You started this thread
with a condescending tone and you’ve already spent more time (and your
enterprise’s money) ranting about this than it’s going to take you to
make this change when it comes, and you continue to be insulting with
comments about being selfish and unprofessional. If you’d like a civil
conversation, then drop the attitude.

I explained my position in another post in this thread, and I look
forward to your respectful responses to those thoughts.

Cheers,
David

#11

David C. wrote:

I explained my position in another post in this thread, and I look
forward to your respectful responses to those thoughts.

I regret if my initial observation was taken as anything other than
that, an observation. One might consider it the textual equivalent to a
raised eyebrow, no more. Being told to maintain my own fork of a
project was not a response that I either expected or thought warranted.

Notwithstanding the heat that this issue appears to have raised, I
assure you that I bear no ill will towards any. I simply believe that
changes which introduce breakage to previously working code should be
avoided wherever possible. This did not seem to me condescending,
abrasive, or particularly controversial. Evidently I am wrong.

#12

On 10/02/2009, at 10:09 PM, James B. wrote:

I simply fail to see why evolving a tool in “better ways” necessarily
requires that the formerly “better” but now depreciated method be
removed. Such action causes avoidable and pointless work. I
consider my
observation to be both reasonable and pertinent.

I hear what you’re saying, James, and agree with you to a certain
extent. However, one must keep a few things in mind:

  1. The syntax in question will be valid, but deprecated, in all 1.x
    releases. This means that you can continue to use the old syntax.

  2. If you’re willing to change which version of RSpec a project of
    yours uses, then you must be willing to change how the project uses
    RSpec. Change begets change.

  3. When a new major version of a project is released, one must be
    prepared for major changes. If the changes are incompatible with you
    or your own software, several options exist:
    3.1) Do not upgrade to the new major version.
    3.2) Fork the new major version, add your desired modifications, then
    use that fork in your software.
    3.3) Modify your software so that it becomes compatible with the new
    major version of the project in question.

  4. Most free and/or open-source projects are run as democracies.
    However, they are overseen by the lead maintainer(s), who have the
    final say when it comes to making decisions. This is because they have
    the most knowledge of, and experience with, the project, and
    understand best the direction that the project should be going in.

Cheers,
Nick

#13

On Feb 11, 2009, at 10:53 AM, James B. removed_email_address@domain.invalid wrote:

project was not a response that I either expected or thought
warranted.

Notwithstanding the heat that this issue appears to have raised, I
assure you that I bear no ill will towards any. I simply believe that
changes which introduce breakage to previously working code should be
avoided wherever possible. This did not seem to me condescending,
abrasive, or particularly controversial. Evidently I am wrong.

Cool. Now we can talk. For the record, the thing that struck me as
patronizing was “You are not seriously … simply to tidy up the
syntax” which makes assumptions about the underlying motivations and
positions your issues as more important than mine, or anybody else’s
for that matter. There is a lot more to all of this than meets the
eye. RSpec is a tool, but it is also a community project, which means
it serves many masters and has to balance many forces.

As for the point you make about avoiding compatbility breaking
changes, I agree that that carries some weight, but it is not the only
concern.

One of the biggest problems rspec suffers as a community project is
barrier to entry for contributors based on a public perception that
rspec is bloated and difficult to understand. So I care about bloat,
and this particular issue is about that as much as it is about syntax.

I have more to add, but I’m typing on my phone and my other fingers
are beginning to get jealous of my thumbs. More later.

David

#14

On 11 Feb 2009, at 16:53, James B. wrote:

warranted.
This is the beauty of github: when someone complains about a project,
you can just tell them to fork off!

Matt W.
http://blog.mattwynne.net
http://www.songkick.com

#15

On Wed, Feb 11, 2009 at 6:52 AM, James B. removed_email_address@domain.invalid
wrote:

Further, by its very nature, a tool is used by vastly more people than
those that create the tool, otherwise it has little value. The idea
that a large number of people should be inconvenienced in order that a
few people are not strikes me as rather selfish and frankly,
unprofessional.

You are completely out of line even suggesting that David is selfish
or unprofessional. Do you have any clue how many changes he HASN’T
made because it would break backwards compatibility? How much effort
goes into sensibly deprecating stuff? The work he does to keep RSpec
working with old versions of Rails (only very recently announcing
discontinued support of 1.2.x), as well as consistently keeping it
working with edge Rails even with all of its internal breakage.

The simple fact is that while RSpec owes a great deal to its community
as a whole, it would be nowhere near where it is today without David’s
hard work. Look at the friggin commit logs and the lighthouse
tickets. Do you seriously have a problem with making his life a bit
easier? Didn’t think so. And I can guarantee you that his real
motivation isn’t selfish in the least - cleaning up the internals
makes it easier to understand and modify, allowing more users to
become contributors.

Here’s a little tip that will save you THOUSANDS AND THOUSANDS OF
DOLLARS in the future:
gem install rspec rspec-rails --version=1.1.12

Pat

#16

Pat M. wrote:

You are completely out of line even suggesting that David is selfish
or unprofessional. Do you have any clue how many changes he HASN’T
made because it would break backwards compatibility? How much effort
goes into sensibly deprecating stuff? The work he does to keep RSpec
working with old versions of Rails (only very recently announcing
discontinued support of 1.2.x), as well as consistently keeping it
working with edge Rails even with all of its internal breakage.

I did not believe that what I understood from the choice of words used
with respect to removing part of the RSpec API could be correct and so I
asked whether or not I was mistaken. Evidently because of my phrasing
this was somehow turned into a slur on the people who work on RSpec. I
regret that but no insult was intended, it was just a statement of how I
understood what I had just read incorporated with a request to have my
interpretation corrected. If this had been raised in person and not via
email I venture that my question would have been answered directly and
without rancor.

The initial response that I received from Mr. Dennis was uncalled for.
It would have been enough to say that there exists a compelling
technical reason to remove the item. It would have been useful to
outline briefly what that technical reason was. Bear in mind please
that those outside of the inner circle of contributors generally are not
conversant with all of the issues facing a project. We nonetheless may
possess reasonable concerns with respect to its future development.

I am well aware that Rails is a moving target and that Ruby is about to
go through the convulsions that will accompany the move to 1.9/2.x in
the near future. I expect that in consequence a vast amount of software
presently in use will either have to be revised extensively or
abandoned. I am not dogmatic about backwards compatibly. On the other
hand, I also have first hand experience with OSS projects where
backwards compatibility appeared inconsequential.

Instead of advising people who raise issues like this to go fork their
own project, perhaps a brief statement as to why the action is deemed
appropriate might be better. Compare the response from Mr. Dennis to
that from Mr. Chelimsky.

You may now have the last word.