In fact, Rust separates initialization from allocation. The OP was
correct that new might better be called an initializer, but I think that
ship has sailed---constructor is the generally accepted term for the
function which initiailizes the instance, for better or worse. Still,
for a class C, it is possible to write C(...), @C(...), ~C(...) and so
forth, each of which will allocate memory from a different location
(stack, task heap, exchange heap).
With regions, it will also be possible to use user-specified memory
pools. The current syntax is `new(pool) C`, harkening back to
overloaded-new in C++, but I am not sure if we'll stay with it.
What I mainly dislike about the current constructor system is having to
repeat everything all the time. Sometimes this is ok but usually a
constructor just wants to initialize all (or most) of the fields from
the values given in the parameters. One possibility that patrick and I
had talked about is that if there is no constructor defined, one can
construct the class using a literal syntax like `C { f1: ..., f2: ...
}`. But I am concerned that this is kind of discontinuous with the
constructor---implementing a constructor would then require rewriting
every allocation site.
So perhaps we should just say there is a default constructor of the form:
new(f1: T1, ..., fN: T2) {
self.f1 = f1;
...
self.fN = fN;
}
for each field `f1`, ..., `fN` defined in the class (and in the same
order as they are defined).
Niko
On 4/12/12 12:25 AM, Kobi Lurie wrote:
what about a private new() in the class, that returns the allocated
instance, and a public 'make' fn, with how many overloads you want, to
serve as a ctor. rustc can require that atleast one 'make' fn will
exist for a class, and that it returns the same object that came from
new().
(the user cannot write a fn named 'make', if it doesn't return the
class type, and the actual object from new(). -- if it's possible to
verify such a thing statically)
bye, kobi
On 4/12/2012 7:56 AM, Steven Blenkinsop wrote:
I don't know about your use of the term "constructor", but it is true
that "new" is often associated with the allocation side of things
instead of the initialization side of things in languages that make a
distinction (many don't). Go faces the opposite problem since people
think of "new" as syntax for calling a constructor which does
initialization, and its "new" does allocation. But maybe that just helps
prove your point, which is that people have strong preconceptions about
what "new" means, so it might be worthwhile for Rust to pick a different
word, all else being equal. I can't see it creating huge problems, since
the worst case scenario is that people will continuously be griping
about how "new" is the wrong word, but if you can minimize the number of
perennial meaningless complaints, you have more time to address real
problems.
_______________________________________________
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
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
