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
