Please let's not get derailed here. I wasn't bemoaning the difficulty of implementing list iterators. I was trying to offer a simple example everyone could understand to show when protected might be useful. There are definitely times when implementing an interface that it's more convenient or efficient to use an object's non-public API.
This discussion is not about list iterators, it's about whether it makes sense to have any visibility other than public and private. I argued that protected doesn't buy much over using unsafe private. Another unmentioned approach is to build classes as a composition of traits. Most callers will not be concerned with the internal traits, but users implementing a new trait for a class would use them. Both of those approaches get most of the way to protected without adding the cognitive overhead. So that's my suggestion. On Apr 17, 2013 11:39 AM, "Daniel Micay" <[email protected]> wrote: > On Wed, Apr 17, 2013 at 1:59 PM, Matthieu Monrocq > <[email protected]> wrote: > > > > > > > > On Wed, Apr 17, 2013 at 9:24 AM, Eddy Cizeron <[email protected]> > wrote: > >> > >> > >> 2013/4/16 Brandon Mintern <[email protected]> > >>> > >>> I agree with you completely, Matthieu, but that's not the kind of > thing I > >>> had in mind. Consider a LinkedList implementation. Its nodes and their > >>> pointers would be private to the LinkedList, but when implementing an > >>> Iterator for that list, you would need to use that private information > to > >>> avoid n^2 performance. > >> > >> > >> That's a typical case I had in mind. > > > > > > I am not sure. > > > > Whilst the head of the list will be private to the list, there is no > reason > > that the *node type* be private. Expose the node, built iterators that > take > > a reference to a node in their constructor, and have the list build the > > begin/end iterators (I guess). All iterations can be done safely... > > > > Of course, it does mean that you have an issue whenever you wish to > "erase" > > an item by passing its position (unless you use unsafe code to make the > > reference mutable again). > > > > > > But that is, I think, a wrong example. Iterators are unsafe. You can > easily > > keep dangling iterators aside and having them blow up in your hands. > > > > > > On the other, if we shunt external iterators and implement iteration > with a > > "foreach" method accepting a predicate, then we do not need to expose the > > list internals. Give the predicate the ability to "influence" the list > it is > > running on (returning an enum "Stop/Remove/...") and you are on. > > > > > > I am not saying that there is absolutely no reason it will ever be > needed, > > but I am challenging the needs exposed so far :) > > > > -- Matthieu > > > >> > >> > >>>>> > >>>>> And then I thought about it a little more and realized that this is > >>>>> precisely something that's unsafe. Most of my protected fields and > methods > >>>>> in Java are accompanied by comments like, "Important note: don't > frobnicate > >>>>> a foo without also twiddling a bar." > >>>>> > >>>>> I think you're right, Daniel, that having a layer between public API > >>>>> and present implementation is probably not worth the cognitive > overhead. > >> > >> > >> I understand your point Brandon. But I could say sometime protected > >> information is not so sensitive. When it is immutable for example. So > why > >> not declaring it public? Not to pollute the public interface with data > >> unrelated with the common use (Yes I agree the argument is not very > strong) > >> > >>>>> > >>>>> It seems like it would be Rust best practice when implementing an > >>>>> interface to use the public API of the type to the extent possible, > and when > >>>>> necessary for efficiency or other reasons, to use unsafe and fiddle > with the > >>>>> private API. > >> > >> > >> It could be. But if I'm allowed to play the Devil's advocate this > implies > >> that any implentation detail must be thought as potentially accessible > (and > >> then as necessarily understandable / documented) from outside (what you > call > >> "private API"). This is not the typical approach when considering > private > >> data. > >> > >> _______________________________________________ > >> Rust-dev mailing list > >> [email protected] > >> https://mail.mozilla.org/listinfo/rust-dev > >> > > > > > > _______________________________________________ > > Rust-dev mailing list > > [email protected] > > https://mail.mozilla.org/listinfo/rust-dev > > > > You can write safe external iterators by using lifetimes. The compiler > will enforce that the list is frozen while you have iterators - > completely statically for all owned types, and dynamically for @mut > boxes. > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
