{"action":"created","issue":{"url":"https://api.github.com/repos/gulpjs/value-or-function/issues/5","repository_url":"https://api.github.com/repos/gulpjs/value-or-function","labels_url":"https://api.github.com/repos/gulpjs/value-or-function/issues/5/labels{/name}","comments_url":"https://api.github.com/repos/gulpjs/value-or-function/issues/5/comments","events_url":"https://api.github.com/repos/gulpjs/value-or-function/issues/5/events","html_url":"https://github.com/gulpjs/value-or-function/pull/5","id":165922250,"number":5,"title":"Refactor lenient in strict out","user":{"login":"erikkemperman","id":3100637,"avatar_url":"https://avatars.githubusercontent.com/u/3100637?v=3","gravatar_id":"","url":"https://api.github.com/users/erikkemperman","html_url":"https://github.com/erikkemperman","followers_url":"https://api.github.com/users/erikkemperman/followers","following_url":"https://api.github.com/users/erikkemperman/following{/other_user}","gists_url":"https://api.github.com/users/erikkemperman/gists{/gist_id}","starred_url":"https://api.github.com/users/erikkemperman/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/erikkemperman/subscriptions","organizations_url":"https://api.github.com/users/erikkemperman/orgs","repos_url":"https://api.github.com/users/erikkemperman/repos","events_url":"https://api.github.com/users/erikkemperman/events{/privacy}","received_events_url":"https://api.github.com/users/erikkemperman/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":11,"created_at":"2016-07-16T09:50:25Z","updated_at":"2016-08-06T20:25:44Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/gulpjs/value-or-function/pulls/5","html_url":"https://github.com/gulpjs/value-or-function/pull/5","diff_url":"https://github.com/gulpjs/value-or-function/pull/5.diff","patch_url":"https://github.com/gulpjs/value-or-function/pull/5.patch"},"body":"Cf. [#4](https://github.com/gulpjs/value-or-function/issues/4).\r\n\r\nI thought I'd submit what I have at this point, probably not going to be able to work on this further the next couple of days.\r\n\r\nWhen looking at a project with fresh eyes I tend to have too many ideas, probably some that occurred to you but were rejected. Still, figured I'd list some of them here:\r\n\r\n- Is returning `null` really the most convenient way to signal rejected values? Maybe allow the caller to provide a fallback/default, or even throw a `TypeError`?\r\n- I played around with passing the given value to the uppercase functions like `Number` et. al., without the `new` keyword, to do coercion. However that would probably be _too_ lenient, e.g. `Boolean('foo')` would be accepted. Still, I'd like it if string arguments were supported, for instance if I want to provide options read from a .json file. Unfortunately I don't see clean way to do this without having to implement some functions separately for the various types. Would that be too ugly?\r\n- Would it make sense to support `integer` and `float` separately (where the latter is just an alias for `number`)?\r\n- Out of curiosity, what possible use do you see for type `undefined`?"},"comment":{"url":"https://api.github.com/repos/gulpjs/value-or-function/issues/comments/238047061","html_url":"https://github.com/gulpjs/value-or-function/pull/5#issuecomment-238047061","issue_url":"https://api.github.com/repos/gulpjs/value-or-function/issues/5","id":238047061,"user":{"login":"erikkemperman","id":3100637,"avatar_url":"https://avatars.githubusercontent.com/u/3100637?v=3","gravatar_id":"","url":"https://api.github.com/users/erikkemperman","html_url":"https://github.com/erikkemperman","followers_url":"https://api.github.com/users/erikkemperman/followers","following_url":"https://api.github.com/users/erikkemperman/following{/other_user}","gists_url":"https://api.github.com/users/erikkemperman/gists{/gist_id}","starred_url":"https://api.github.com/users/erikkemperman/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/erikkemperman/subscriptions","organizations_url":"https://api.github.com/users/erikkemperman/orgs","repos_url":"https://api.github.com/users/erikkemperman/repos","events_url":"https://api.github.com/users/erikkemperman/events{/privacy}","received_events_url":"https://api.github.com/users/erikkemperman/received_events","type":"User","site_admin":false},"created_at":"2016-08-06T20:25:44Z","updated_at":"2016-08-06T20:25:44Z","body":"@phated So I've simplified, and squashed everything into a single commit. I've updated the PR to reflect what I ended up with, but I'm not entirely sure about this...\r\n\r\nFor one thing, it is now somewhat less forgiving of input types as I had originally imagined it might be, by not accepting strings for the built-in types (I was thinking that command-line options and configuration files might be a common source of strings that folks would like to coerce).\r\n\r\nOf course it's a perfectly reasonable argument that that kind of thing should be handled externally if needed. On the other hand, perhaps I was just being much too particular about the string values I wanted to accept, and a simpler approach (just calling the native coercers `Number(...)` et. al.) might have been more palatable?\r\n\r\nCompared to master, this branch effectively just adds support for `new Number`, `new Boolean` and `new String`. And I guess it cleans up `.date` a little in that it is now integrated with the other types and thus satisfies `vof.normalize('date', ...) === vof.normalize.date(...)`. If this smaller change had been my target from the start, perhaps I would have done it differently, or even decided the benefit doesn't outweigh the burden of added complexity.\r\n\r\nSo I'm not sure if/how to proceed with this, curious if you have ideas.\r\n\r\nSorry for being so verbose again, but two more general thoughts I had going over this, which apply to current master as well I suppose:\r\n\r\nDoes it actually make sense to expose `normalize.function`? It complicates handling of function-values (more so with `coerce` logic than it did with `conforms`, but still).\r\n\r\nI would think that `null` ought to be valid input for `normalize.object`, but that's a little bit awkward in that we can't simply conclude that a `null` return value signals unacceptable input. Maybe I am overlooking some intended purpose for `normalize.undefined` but if not, I might propose to remove it and adopt `undefined` as unambiguous return value for bad input?\r\n\r\nPS I just noticed that coverage went down, I'll take a quick look at that now.\r\n"}}
{"actor":{"display_login":"erikkemperman"}}