You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems to me that this might not be an intentional limitation.
Shouldn't these methods be defined on SequenceableCollection?
One peculiar side effect is that Array.fillNoteNames clobbers Array.fill in SC-IDE's auto-completion menu. *fill is defined on Collection, so it ends up lower in the list than the less-frequently-used *fillNoteNames. I believe this would be avoided by defining it higher in the class tree.
The text was updated successfully, but these errors were encountered:
Hi James, sorry for the delay, just checking issues now. Yes, makes sense. It would require a bit of rework though, if I just change Array into SequenceableCollection the code "List.fillNoteNames" will render an Array of notenames instead of a list (don't know if that's necessarily a problem but it would seem a bit unclear). Also, I just tried, but it seems that for the completion menu it doesn't make a difference if fillNoteNames is in Array or SequenceableCollection; it still shows up first..
In a class method, using this to invoke the specific subclass is a common pattern. (collectAs is needed because aList.collect produces an array, grrrr.)
Similar could be applied to other methods in the same file.
It seems to me that this might not be an intentional limitation.
Shouldn't these methods be defined on SequenceableCollection?
One peculiar side effect is that Array.fillNoteNames clobbers Array.fill in SC-IDE's auto-completion menu.
*fill
is defined on Collection, so it ends up lower in the list than the less-frequently-used*fillNoteNames
. I believe this would be avoided by defining it higher in the class tree.The text was updated successfully, but these errors were encountered: