On Wed, Apr 17, 2013 at 9:24 AM, Eddy Cizeron <eddycize...@gmail.com> wrote:
> > 2013/4/16 Brandon Mintern <bran...@mintern.net> > >> 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 > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
