On 7/10/12 6:41 PM, Sebastian Sylvan wrote:
It would be cool if tasks started out more like PPL/TBB/Cilk tasks and
transitioned into the current thread-like construct and allocated
stack space only if needed. I.e. the first time a task needs to yield
its underlying "worker thread" (because it's a
On Tue, Jul 10, 2012 at 6:05 PM, Brian Anderson wrote:
> Tasks do have a memory cost, but it is theoretically quite low. Rust tasks
> on linux currently have somewhere around 4K of overhead, and that's around
> 3K more than we would like and think is possible. Most of that is dedicated
> to the ca
On Tue, Jul 10, 2012 at 6:24 PM, Alexander Stavonin
wrote:
> I've found mentions of Reflection system in "Doc detailed release notes",
> unfortunatly the explanation is totally unclear for me. After that, I found
> reflect-visit-data.rs file, which was not too helpfull. Is it possible to
> clarif
I've found mentions of Reflection system in "Doc detailed release notes",
unfortunatly the explanation is totally unclear for me. After that, I found
reflect-visit-data.rs file, which was not too helpfull. Is it possible to
clarify Reflection system description, provide some use cases, etc?
__
On 07/10/2012 12:13 PM, David Bruant wrote:
Hi,
I've recently watched a Google I/O talk on Go Concurrency Patterns [1]
and I find some patterns worrisome. Go has made some choices, but I'd
like to understand how Rust addresses these issues.
Disclaimer on my background: I've learned programming m
Hi,
I've recently watched a Google I/O talk on Go Concurrency Patterns [1]
and I find some patterns worrisome. Go has made some choices, but I'd
like to understand how Rust addresses these issues.
Disclaimer on my background: I've learned programming mostly in C, then
a bit of Lisp, a good share o
Le 10/07/2012 18:51, Graydon Hoare a écrit :
> On 7/10/2012 9:04 AM, David Bruant wrote:
>
>> If I can "concretize" a trait for an arbitrarily complex structure, why
>> would I create classes? Or could classes be seen as syntactic sugar over
>> traits+types?
>
> Sugar, mostly. We're still trying to
On 7/10/2012 9:04 AM, David Bruant wrote:
If I can "concretize" a trait for an arbitrarily complex structure, why
would I create classes? Or could classes be seen as syntactic sugar over
traits+types?
Sugar, mostly. We're still trying to decide how sweet to make it. Also
they introduce a nomi
Le 10/07/2012 17:45, Sebastian Sylvan a écrit :
On Tue, Jul 10, 2012 at 4:15 AM, David Bruant wrote:
Why having both classes and traits? Both are mechanisms to enable code
reuse.
I guess I should restate my question: In which case would I use traits over
classes or classes over traits?
As I un
On 7/10/2012 4:15 AM, David Bruant wrote:
I wish that instanciating a character (for a given type) shows the
drawCharacter method, but not any of the low-level drawing methods. I
don't think it's possible to make Dot and Shape methods module private
since Character could be in a different module
On Tue, Jul 10, 2012 at 4:15 AM, David Bruant wrote:
>
> Why having both classes and traits? Both are mechanisms to enable code
> reuse.
> I guess I should restate my question: In which case would I use traits over
> classes or classes over traits?
As I understand it traits are the code-reuse par
Le 10/07/2012 01:33, Patrick Walton a écrit :
On 7/9/12 2:44 PM, David Bruant wrote:
As far as I can tell, the visibility control issue is not taken care of.
What it means is that when a trait is composed of other traits, the
instances of these traits have every single method of all the traits.
12 matches
Mail list logo
