Recently I saw a video of person from scala team who regretted some 'pragmatic' choices in long run so I might be still under it's impression regarding pragmatic choices in a language. Fortunately (or unfortunately) I'm not in charge of Rust design.
Also last question - why not use:
struct Element {
//... element specific elements
}
struct Attribute {
//... attribute specific elements
}
enum NodeChild {
NodeAttribute(Attribute),
NodeElement(Element)
}
struct Node<'r> {
parent: &'r Node,
first_child: &'r Node,
last_child: &'r Node,
next_sibling: &'r Node,
last_sibling: &'r Node,
node: NodeChild
}
For static types:
struct Element<'r> {
elem: &'r Node
}
pub fn downcast_to_element<'r>(node: &'r Node) -> Option<Element<'r>> {
match (node.node) {
NodeElement(_) -> Some(Element {elem: node}),
_ -> None
}
}
+ impl with potentially partial methods? Is the 'all nodes consuming
same amount of memory' too much memory?
1. One word pointers - check
2. Access to fields - check
3. Downcasting and upcasting - check
4. Inheritance with prefix property - check (sort of)
5. No need for behind-the-back optimization - check
-. static dispatch (check) at the cost of match instead of jump with all
its pros and cons
Best regards
On Tue, 2014-03-11 at 19:47 -0700, Patrick Walton wrote:
> 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) does this sort of hack really result in a
> cleaner design than having some simple language extensions? Mind you,
> I'm all about ways to simplify Rust, but sometimes the simplest
> solution is to build stuff into the language.
>
> On March 11, 2014 7:39:30 PM PDT, Maciej Piechotka
> <uzytkown...@gmail.com> wrote:
> 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 while I was
> learning ruby) and I don't think there was a problem
> of OO - main
> problem was mapping libxml memory management and
> rust's one [I gave up
> with namespaces but with native rust dom
> implementation it would be
> possible to solve in nicer way]. Of course - I
> might've been at too
> early stage.
>
> You need:
>
> 1. One-word pointers to each DOM node, not two. Every DOM
> node has 5
> pointers inside (parent, first child, last child, next
> sibling, previous
> sibling). Using trait objects would 10 words, not 5 words,
> and would
> constitute a large memory regression over current browser
> engines.
>
> 2. Access to fields common to every instance of a trait
> without virtual
> dispatch. Otherwise the browser will be at a significant
> performance
> disadvantage relative to other engines.
>
> 3. Downcasting and upcasting.
>
> 4. Inheritance with the prefix property, to allow for (2).
>
> If anyone has alternative proposals that handle these
> constraints that
> are more orthogonal and are pleasant to use, then I'm happy
> to hear
> them. I'm just saying that dismissing the feature out of
> hand is not
> productive.
>
> Patrick
>
>
>
> Ok. I see where my misunderstanding was - I was thinking
> about DOM
> implementation in Ruby for Ruby while you (Mozilla) were talking about
> implementation in Ruby for JavaScript.
>
> Please feel free to ignore next paragraph as I haven't given it much
> though but my guess would be that it would be possible to avoid the
> penalty by enum + alignment + smart compiler. As data have 6 words +
> in
> your scheme (5 described + vtable) the 4 bit alignment (assuming 32+
> bit
> platform) should not cause much memory waste. This allows for using
> the
> 'wasted' bits for other purposes (the trick is used in, for example,
> lock-free structures) - for example:
>
> enum ElementChild<'r> {
> ElementChildElement(&'r Element),
> ElementChildComment(&'r Comment),
> }
>
> Could be represented as pointer with last bit specifying if it's
> element
> or comment - similar to Option<&T> optimization. The lookup should
> behave much nicer with respect to branch prediction
> (plus) but getting
> pointer is more complicated (minus) and possibly longer code instead
> of
> jump (minus). If data alignes the compiler should be able to optimize
> the jumps if it notices that all jumps lead to the same pointer
> arithmetic. I'm not sure about handles from JS but I don't think there
> is more then 16 choices for types of parent/child/sibling for any node
> so it should be achivable - on language side it would just be enum +
> pointer (+ specification of alignment as attribute?).
>
> That said a) I have done no measurements/benchmarks so my intuition is
> likely to be wrong b) should in above paragraph means 'it looks that
> it
> could work after 5s thought' and c) I'm not a Rust designer and I
> don't
> pay for nor contribute so I don't expect that I should have anything
> resembling last word.
>
> Best regards
>
>
> ______________________________________________________________
>
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
