On 05/20/2012 05:23 AM, Bennie Kloosteman wrote:
New member to the list im no genius but am looking for a replacement
for c for system programming.
1) Great work on UTF8 strings and USC4 chars ( I do some work with
chinese chars and USC-2 just doesn't work here) . BTW why null
terminated strings if you have arrays . Any c interop will require
conversion to Unicode chars anyway fr a generic lib ( and for most
IO the perf cost of a copy is pretty irrelevant)
At the moment we aren't willing to risk that the cost of a copy for C
interoperability is irrelevant. Might be worth measuring once we have
more of Servo up and running though. (The operative constraint here is
basically that it's fast enough to build a competitive browser with.)
, Speaking of which
its very useful in strings keeping the char count as well as the byte
length mainly so you can go if ( str->length == str->count) to avoid
any Unicode parsing when you convert to ascii. ( you could use a
flag or the high bits of a int64 ) - or use a subtype stating its
ASCII.
Interesting idea. Patches welcome!
2) Does Rust have anything like bitc HasField ,?
BitC introduced has field constraint and this was very useful , the
field could be a function or property
but you can then put on a method that the type HasField x and like
an interface it hides the implementation ,
you could use any type with met the constraint. .
I don't see any reason why we couldn't have HasField, although none of
us have needed it yet.
It also meant encapsulated types and the associated "this" pointer /
vcall issues could possible be avoided since the method only specified
what filed it used the rest would be private ( for that method) .To
me this greatly reduced the need of having private fields/members
which existing c programmers will just follow as they find it hard to
pick up type classes initially. You may be able to use hashfield for
a fascade to further effect to hide internals . Since you guys are
now considering this and objects I would read the below comments very
carefully.
I have ideas as to how we could implement inheritance if we need it (and
I think we might well need it, as I'm running into issues with not being
able to exploit the prefix property for subclassing with Servo). It's
not totally sketched out, so I don't have a concrete proposal. That
notwithstanding, basically it involves unifying enums and classes so
that (a) enum variants are actual types, subtypes of the enclosing enum
to be exact; (b) enums are classes and can have fields and methods; (c)
enum variants can access fields and methods of the enclosing enum; (d)
enum variants can contain other sub-variants.
Patrick
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
