Hey rusties!
I just wanted to remind everyone we have another meetup this Thursday, 7PM
at Mozilla SF, where Julia Evans will talk about the OS she built with
Rust. Here's the link to sign up:
http://www.meetup.com/Rust-Bay-Area/events/166034142/
I hope you can make it!
Erick
I see a proposal to add virtual struct and virtual fn in the workweek
meeting notes, which appears to add an exact copy of Java's OO system to Rust.
I think however that this should be carefully considered, and preferably not
added at all (or failing that, feature gated and discouraged).
The
On Tue, 2014-03-11 at 19:09 +, Bill Myers wrote:
I see a proposal to add virtual struct and virtual fn in the workweek
meeting notes, which appears to add an exact copy of Java's OO system to Rust.
I think however that this should be carefully considered, and preferably not
added at
On Tue, 2014-03-11 at 14:37 -0500, Evan G wrote:
... Why didn't they just extend Number? (Or, at worst, that was a bad
design decision on Oracle's part, by choosing to make the Float class
final)
Either way, I don't see how that's a fault of the language.
I don't remember - maybe they
I like virtual functions. They're not for everything, and stylistically,
traits are almost always a better solution. However, they can be nice to
reduce code bloat. See how the LLVM devs managed to share a good amount of
code for their SmallVector class thanks to the magic of virtual functions:
Bill's posting pleases me more than any other I have seen
so far.
Virtual functions in C++ have been an especially fruitful
source of unfortunate consequences, both in the language and
in users' programs. It is common in C++ coding guidelines
to forbid public virtual functions, to help avoid
See for example
http://jscience.org/api/org/jscience/mathematics/structure/Field.html
and
http://jscience.org/api/org/jscience/mathematics/number/Float64.html.
Now you cannot just use Double as to use
http://jscience.org/api/org/jscience/mathematics/function/Polynomial.html you
need to have a
On 11/03/14 03:59 PM, Clark Gaebel wrote:
I like virtual functions. They're not for everything, and stylistically,
traits are almost always a better solution. However, they can be nice to
reduce code bloat. See how the LLVM devs managed to share a good amount
of code for their SmallVector
On 3/11/14 1:42 PM, Daniel Micay wrote:
Existing object systems like COM, DOM and gobject are worth looking at,
but Rust shouldn't bend over backwards to support them. They're legacy
technologies and while interacting with them is important, I don't think
it should result in any extra complexity
On 3/11/14 12:09 PM, Bill Myers wrote:
I see a proposal to add virtual struct and virtual fn in the
workweek meeting notes, which appears to add an exact copy of Java's
OO system to Rust.
I think however that this should be carefully considered, and
preferably not added at all (or failing that,
The downsides you list are all more or less applicable to this design,
indeed. We are seeing real requirements in real code that indicates that
the current abstraction facilities provided by Rust are efficient enough
for certain demanding use cases (the DOM in particular).
Here are the
On 3/11/14 1:42 PM, Daniel Micay wrote:
Traits already provide a choice between monomorphization and virtual
function tables. I hope that the existing system can be extended in an
orthogonal way. I would be very disappointed if Rust ended up like C++,
where you have two almost completely
On 03/11/2014 04:52 PM, Brian Anderson wrote:
Fortunately, this feature is independent of others and we can feature
gate it until it's right.
I think that's the crux of the issue some have with this. If a whole
another, completely disjoint path for inheritance and dynamic
polymorphism is
On Tue, 2014-03-11 at 13:44 -0700, Patrick Walton wrote:
On 3/11/14 1:42 PM, Daniel Micay wrote:
Existing object systems like COM, DOM and gobject are worth looking at,
but Rust shouldn't bend over backwards to support them. They're legacy
technologies and while interacting with them is
On 3/11/14 2:09 PM, SiegeLord wrote:
On 03/11/2014 04:52 PM, Brian Anderson wrote:
Fortunately, this feature is independent of others and we can feature
gate it until it's right.
I think that's the crux of the issue some have with this. If a whole
another, completely disjoint path for
On 3/11/14 2:15 PM, Maciej Piechotka wrote:
Could you elaborate on DOM? I saw it referred a few times but I haven't
seen any details. I wrote simple bindings to libxml2 dom
(https://github.com/uzytkownik/xml-rs - warning - I wrote it while I was
learning ruby) and I don't think there was a
FWIW, C# requires that you mark overridable functions *virtual*, the
opposite of Java where you need to mark un-overridable functions *final*.
The Scala community is coming to the same conclusion that unrestricted
overriding is pretty dangerous. It's similar to monkey patching, with all
the
On 3/11/14 2:19 PM, Haoyi Li wrote:
FWIW, C# requires that you mark overridable functions *virtual*, the
opposite of Java where you need to mark un-overridable functions
*final*. The Scala community is coming to the same conclusion that
unrestricted overriding is pretty dangerous. It's similar
I can't help but feel that forcing the single inheritance of fast field
access and inheritance of trait functions into one mechanism would be
regrettable.
Would https://github.com/mozilla/rust/issues/10491 address all the
requirements? If not, why?
On Tue, Mar 11, 2014 at 10:52 PM, Brian
By the way, I didn't see any discussion of the HasPrefix/Coercible
proposalhttps://github.com/mozilla/rust/issues/9912#issuecomment-36073562in
the workweek minutes. Did anybody bring it up at all?
Vadim
On Tue, Mar 11, 2014 at 2:30 PM, Oren Ben-Kiki o...@ben-kiki.org wrote:
I can't help but
I've actually come around and now I'm starting to actually like this
virtual struct proposal, although not necessarily the example syntax (yay
bikeshed!). What brought me around is that if you squint your eyes a bit,
the example was mashing together struct inheritance and virtual methods
into one
Hey, Rusties.
The freewheeling way that we add new features to Rust has been good for
early development, but for Rust to become a mature platform we need to
develop some more self-discipline when it comes to changing the system.
So this is a proposed modification to our current RFC process to
Thanks for this. This sounds great. We should form a group on Thursday at
the meetup and come up with that checklist. I can help track down the
doc-less APIs Friday night and some of Saturday too.
On Mon, Mar 10, 2014 at 5:38 PM, Brian Anderson bander...@mozilla.comwrote:
Hey,
As you may
On Tue, 2014-03-11 at 14:18 -0700, Patrick Walton wrote:
On 3/11/14 2:15 PM, Maciej Piechotka wrote:
Could you elaborate on DOM? I saw it referred a few times but I haven't
seen any details. I wrote simple bindings to libxml2 dom
(https://github.com/uzytkownik/xml-rs - warning - I wrote it
I thought about tricks like this, but (a) a sufficiently smart compiler should
*not* be doing this automatically, as it makes certain common operations like
fetching the pointer more expensive as well as violating the principle of least
surprise when it comes to machine representation, and (b)
25 matches
Mail list logo
