Curry Exercise 2: filterQs does not, in fact, filter Q's about mostly-adequate-guide HOT 10 CLOSED

Ahhh, thank you. There was a previous pull request to use ramda's version as it's explicitly required. The tests still passed since we only updated the book text. I need to work out a way of pointing to the book's definitions of things like match so people don't get confused.

from mostly-adequate-guide.

I was confused by this one too and was about to open an issue. Just saying :)

from mostly-adequate-guide.

There is codepen with the issue, if it will help somehow http://codepen.io/sol0mka/pen/eNqPPx?editors=001

from mostly-adequate-guide.

I am confused, are you saying that using R.match solves this? Ramda's .match seems to return an empty array as well.

How about this?

var test = function(what, x) {
  return _.test(what);
};

var filter = function(f, xs) {
  return _.filter(f);
};

var hasQs = test(/q/i);

var filterQs = filter(hasQs);

from mostly-adequate-guide.

Hey!
Not sure the issue is still relevant here.

Using the match and filter functions provided in the support library, the solution indicated is okay.

// --- In support.js
match = curry(function(what, x) {
    return x.match(what);
});

filter = curry(function(f, xs) {
    return xs.filter(f);
});

// --- Exercice
var filterQs = filter(match(/q/i))

which is relatively equivalent to your proposal though it does not require anything else but the native JavaScript functions.

@craigdmckenna Do you face any issue with the current solution ?

from mostly-adequate-guide.

@KtorZ

I was using JS Bin to complete the exercises and thus had no reference to the helper functions on the repo. The flow of the chapter led me to assume that I should write my own helper functions as in the preceding examples. I also assumed that match() would use String.prototype.match().

I solved it using RegExp.prototype.test().

Then I decided clone the repo to "peek" at the answers but first I ran the tests which also confused me because all but one test passed and I hadn't written any code yet so I commented out require('../../support');

.match() just doesn't seem like the best solution in either of the two situations. Granted, I did make some assumptions regarding it's use. I'm just not sure that the book is quite clear on this. I do feel, however that I have learned much through this process.

from mostly-adequate-guide.

Also, I guess I'm still not sure how the tests pass when the match() helper function uses .match() which returns an array not a Boolean.

from mostly-adequate-guide.

Running the test runner on the answer folder works fine.
However, you're completely right about the wrong use of the match function whereas we should have used test. match is more versatile and therefore, most of the time, one also uses it to simply check whether the string can be matched or not (in case of match, the function returns an array otherwise, null which is a falsy value).

I'll have a look and will likely do a little PR about this :)

from mostly-adequate-guide.

Maybe Ramda should change ;-)

On Feb 5, 2016, at 11:21, Matthias Benkort [email protected] wrote:

Running the test runner on the answer folder works fine.
However, you're completely right about the wrong use of the match function whereas we should have used test. match is more versatile and therefore, most of the time, one also uses it to simply check whether the string can be matched or not (in case of match, the function returns an array otherwise, null which is a falsy value).

I'll have a look and will likely do a little PR about this :)

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

from mostly-adequate-guide.

I know this is closed but I just wanted to clarify something. My confusion came form not understanding that _.SameNameAsJSMethod() is not the same as the JavaScript method of the same name.

The book explained that Ramda has currying built in which lead me to believe that calling R.whatever or _.whatever (as it's used in the book) was somehow currying native JavaScript Methods because there was no explanation of the libraries 'custom' functions.

For someone who is familiar with libraries like underscore or lodash this may not be an issue.

In other words.

.match() // JavaScript method

_.match() // or
R.match() 
// is a custom, functional implementation of .match() 
// in the given library (underscore, lodash, ramda...)
// which may or may not behave exactly like
// it's native JavaScript counterpart

from mostly-adequate-guide.