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.
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
Make Array iterator classes private to hide implementation from client #193
base: main
Are you sure you want to change the base?
Make Array iterator classes private to hide implementation from client #193
Changes from 3 commits
e6691a1
84535ad
42b09a7
5f5d79f
a52eb5f
73099ee
873c378
b0fd354
f492370
62a7b03
48fc8bd
255c487
869eb82
2bfd088
7bf7641
06018fc
e60bb5a
16ec9ef
5b91ce2
7fda29d
4363ab0
5dbe1ca
68b7695
c0da56d
b539018
44103dd
d61d656
18f8d49
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.
There's no need for
is Iterator[A]
as far as I can tell here. Is this an attempt to make sure in the future that RewindableIterator doesn't diverge at all from Iterator?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.
That's true for
interface
but I just kept with the coding style of the stdlib where numerous classes (i.e.Array
,String
,List
,Range
,Reverse
,HashSet
, etc.) explicitly name the interface they implement.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 in the case of those, it made sure that if the Iterator interface was changed that all those concrete classes would fail compilation, is that the intention here? If yes, I think there is a larger discussion about the idea of duplicating the methods from Iterator in RewindableIterator and then using
is
to enforce the Iterator interface.It feels odd. It might be worth it to avoid having an interface that is only
rewind
and the returning the two interfaces, but, it does feel odd and I think the reasoning is worth discussion.I know you had some conversation around this with @jemc. I think you should discuss with him some supporting justification for this. Is this a one off? Is this establishing a pattern that we want to use in the standard library? Is it a pattern that is already being used in the standard library?
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.
My suggestion would be to keep the
is Iterator[A]
part and remove the explicitnext
andhas_next
definitions.For an
interface
, that roughly reads as:RewindableIterator[A]
, you need to implement everythingIterator[A]
requires (which doesn't need to be repeated here), but you additionally need to implement thisrewind
method."Or from the perspective of the interface user:
RewindableIterator[A]
, it can do everythingIterator[A]
can do (which doesn't need to be repeated here), but you additionally can use it torewind
"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.
As noted below by me, I prefer the alternative design of not having
RewindableIterator[A]
overlap withIterator[A]
and instead haveIterator[A] & Rewindable[A]
defineRewindableIterator[A]
.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 don't understand what is finally desired here. What would be the
RewindableIterator
(orCollectionIterator
) definition so that I can include it in the RFC text?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.
Nothing in this section seems to be about teaching people anything going forward about the pattern nor explaining to people impacted by the breaking change what they need to be aware of. This section should be devoted to what if anything should be done with Pony Patterns, the Pony tutorial, standard library documentation, and release notes to adapt to the new world this RFC would bring about.
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.
@pmetras - "How We Teach This" could include a post on the "Pony Patterns" site that demonstrates how to use a public interface to hide the implementation of a private class, rather than making that class public.
Like you, I see this as a desirable design pattern, so we could have a "Pony Patterns" example showing how we did this in the Pony standard library with
Iterator
s (assuming we can get the RFC approved).