-
-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
isEmptyString & isNonEmptyString #40
Comments
@tycho01 need some collaboration over this. Does this even make sense ? Thought I have one production use case in my current project. const description = 'user input';
if (isNotNull(description) && isNotEmptyString(description)) { return description } |
Sounds like just But yeah, why not? :) So I've personally tended toward higher abstraction, and wanted a slightly different truthy/falsy check for arrays/objects, here's what I've been using for that.
For other cases, in the case one would prefer higher abstraction, where you want a function version of the built-in truthy/falsy check, one could also use the built-in |
if (isNotNull(description) && isNotEmptyString(description)) { return description }`
if (description !== null && description !== '') { return description } Also I like you falsy, truhy approach ;] |
Yeah. I wish the built-in checks used this logic for truthy/falsy; it could make things a bit more terse when checking objects/arrays... |
Back to the original problem...it seems that isNotEmptyString doesn't make sense alone. if (isString(description) && isNotEmptyString(description)) { return description }` What makes more sense is isNotEmptyString = both(isString, complement(isEmptyString)); |
|
isEmptyString = eq('');
isNonEmptyString = both(isString, complement(isEmptyString));
isNonEmptyString(null) -> false
isNonEmptyString('test') -> true
isNonEmptyString(udefined) -> false
isNonEmptyString('') -> false Ok I guess it make sense now, thanks. Renamed to isNonEmptyString to distinguish that this is not just a simple complement. |
Conclusion: Implement two new type functions // isEmptyString :: * -> Boolean
export const isEmptyString = equals('');
// isNonEmptyString :: * -> Boolean
export const isNonEmptyString = both(isString, complement(isEmptyString)); @tycho01 thanks for all your input. |
Sure. :) |
@guillaumearm wanna take this one also ? |
Absolutely :-D |
I'm on it ;-) |
I have a problem with the proposed // isEmptyString :: * -> Boolean
export const isEmptyString = equals(''); @char0n : Should Edit: // isEmptyString :: * -> Boolean
export const isEmptyString = both(isString, isEmpty);
// isNonEmptyString :: * -> Boolean
export const isNonEmptyString = both(isString, isNotEmpty); |
IMHO it should return false for Regarding the composition, I understand the consistency argument, but again in JavaScript it is case that If you look at the source of |
OK, it sounds good, but i have some trouble in > R.isEmpty(new String('abc')) // => false
> R.isEmpty(new String()) // => false so there is a problem here : eq(RA.isNonEmptyString(new String('abc')), false); // test throw |
We can get around using a kind of const isPlainString = x => typeof x === 'string' |
What about something like this one ? const isNonEmptyString = R.allPass([RA.isString, RA.isNotObj, RA.isNotEmpty]); |
I don't know. But according to you, which one is fastest ? const isNonEmptyString = R.allPass([RA.isString, RA.isNotObj, RA.isNotEmpty]); or const isPlainString = x => typeof x === 'string';
const isNonEmptyString = both(isPlainString, isNotEmpty); Need benchmark ? |
I'd prefer also the first one even though it is going to be slower. In the context of Equational Reasoning I prefer to compose new parts from the parts that are already available rather than create new add hoc parts just to satisfy the speed property. My main argument in previous comment was not about speed it self but the simplicity. Speed is secondary in this case. |
Ok, so I go for the first solution, did you want I create 2 PRs ? |
yup thanks |
No description provided.
The text was updated successfully, but these errors were encountered: