I favor this approach too. As an example, Scala does something similar: a
call to Map() constructs an immutable map object (it is in the default
namespace), whereas if you want a mutable Map object, you have to import it
from scala.collection.mutable.Map.
--
Ziad
On Fri, Dec 20, 2013 at 10:50
Hello,
Is it possible to some one to explaion why the UK servers are all down ?
i know the game is a beta but because i pay for it and its not free 4 play
i think ppl deserve an explanation why the servers are down for the last 20
hours.
Regards,
Pedro
I like Iter suffix, short, and say what it is.
在 2013年12月21日 下午12:51，Palmer Cox palmer...@gmail.com写道：
I noticed recently that there seem to be 3 distinct Iterator naming
conventions currently in use:
1. Use the Iterator suffix. Examples of this are SplitIterator and
DoubleEndedIterator.
2.
I'm not a big fan of Hungarian notation either. I'm not sure that having a
naming convention for Iterators is Hungarian notation, however. For
example, if you are doing Windows programming, you'll see stuff like:
DWORD dwFoo = 0;
In this case, the dw prefix on the variable indicates that we have
Iterators are just structs which implement the Iterator or a related
trait, right?
These structs which do can also implement lots of other traits, too:
no reason to make -Iter special.
Kevin
On Sat, Dec 21, 2013 at 12:50 PM, Palmer Cox palmer...@gmail.com wrote:
I'm not a big fan of
Are there examples of structs that implement Iterator that also implement
other non-Iterator related traits? Although its possible to do that, I
can't think of a use case for it off the top of my head. An Iterator
basically represents the state of an ongoing computation and once that
computation
Rust's standard libs are still pretty thin on their trait hierarchies,
but I'm sure this will change.
Kevin
On Sat, Dec 21, 2013 at 1:30 PM, Palmer Cox palmer...@gmail.com wrote:
Are there examples of structs that implement Iterator that also implement
other non-Iterator related traits?
The reason the Iterator suffix was removed is because when when one is
required to write the type signature it becomes hugely annoying to
keep writing Iterator all the time. Personally I think Alex's idea is
a good way forward.
On Sat, Dec 21, 2013 at 4:35 PM, Kevin Cantu m...@kevincantu.org
I prefer the 'no suffix' option and generally agree with Alex.
Iterators aren't special and their iterator behavior is already denoted by
implementing the Iterator trait.
Frankly, aside from documentation where it is clear that something is an
iterator, I'm not sure when a user would even see
IMO the best alternative for a non-blocking send on a bounded channel is
returning an Option.
If you send successfully, you return None.
If you can't send because the channel is full, you return Some(message).
This lets the sender recover the message (important for moveable objects)
and decide how
Eric, thats exactly why I suggested the use of the Result or Either type.
Some is a bit misleaning, because the Nothing case is usually means a
failure rather than a success.
On Sat, Dec 21, 2013 at 9:33 PM, Eric Reed ecr...@cs.washington.edu wrote:
IMO the best alternative for a non-blocking
I disagree. Option is precisely the right type because all Option means is
you can get something or nothing.
Sometimes it can make sense to consider 'something' success and 'nothing'
failure, like attempting to parse a string.
Sometimes it can make sense to consider 'nothing' success and
12 matches
Mail list logo
