This repository has been archived by the owner on May 5, 2021. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
master-modifier-contains-nby #453
base: master
Are you sure you want to change the base?
master-modifier-contains-nby #453
Changes from all commits
721fab7
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Du coup pour rester dans l'esprit des autres méthodes, ce serait bien d'aussi accepter
...modifiers: Array<Modifier | Constructor<Modifier>>
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I specifically need to check if
Modifiers
are contained, notModifier
.Including
Constructor<Modifier>
would introduce a new logic that I think is useless.Modifier.isSameAs
does not takeConstructor<Modifier>
.If we need to check the constructor, then using a
.filter()
would be sufficient as we don't need to check the undefined.On the other hand I could use
Modifier[]
in the signature. Which could have two forms:or:
Which one you prefer @dmo-odoo @Zinston ?
I've push the first version as I found it more elegant but I'll change it if you have a different taste.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason I suggested to include the other types was that most methods in
Modifiers
do and that this one is not fundamentally different from the others so from an API perspective I would expect to be able to use this one the same was as the others. Even though it admittedly adds a little bit of logic. As you said though:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So what do I do?
Do I continue to take
Modifiers
as argument?Do I add the logic for Contructor ?
If I take it all it means the function would become this:
Which becomes complicated to read for not so much value.
And also if I want consistencies, it means that all other method should have the same signature (i.e. including
Modifiers
).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To summarize some of the options:
...modifiers: (Modifier | Constructor<Modifier>)[]
Modifiers
modifiers: Modifiers | Modifier[]
modifiers: Modifiers | (Modifier | Constructor<Modifier>)[]
...args: [Modifiers] | (Modifier | Constructor<Modifier>)[]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
[...modifiers] would magically call Modifiers.clone ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've tested I it does not work. You need
f(...[...modifier])
.Then the code would be:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first
...
is the syntax to specify that you want an array being considered as the list of arguments.So you need to
...
over an array.The second
...
mean taking an iterable (here otherModifier) and place it in an array through the spread operator.I think the first
...
is not considered as a spread operator although it is written the same way.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mmmh... Then what about this:
Wouldn't
Modifiers
be anIterable<Modifier>
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I already tried. I've tested in javascript and it would work.
The problem is typescript.
If you do
fn(...anything: AnyType) {}
, typescript tell you AnyType must be an array of something.An iterable is not an Array so
fn(...anything: Iterable<any>) {}
cannot work.And if you do
contains(...modifiers)
(which would work in js), typescript tells you: