Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Fix name ambiguity in trait object diagram #1292

Closed
mgeisler opened this issue Oct 3, 2023 · 0 comments · Fixed by #1294
Closed

Fix name ambiguity in trait object diagram #1292

mgeisler opened this issue Oct 3, 2023 · 0 comments · Fixed by #1294
Labels
bug Something isn't working good first issue Good for newcomers help wanted Extra attention is needed

Comments

@mgeisler
Copy link
Collaborator

mgeisler commented Oct 3, 2023

So if <Dog as Pet>::name refers to the field name in the Dog struct, what does <Cat as Pet>::name refer to?

Oh, sorry, I misunderstood above. <Dog as Pet>::name is supposed to refer to the Dog::name method.

If you called the field dogname (in the Dog struct) I think it would be clearer what's going on. Then, presumably, the label would become <Dog as Pet>::dogname.

It would make more sense if the ::name refers to the function (though the function isn't really on heap, presumably and the name: Fido would then be dogname: Fido.

Yeah, that is what the picture was supposed to show. I think "the heap" as "somewhere in memory". I guess the vtable is generated at compile-time and put somewhere in the binary — and then memory-mapped into the address space when the program is loaded from disk.

Obviously, I'm confused, but I don't think adding this information to the notes would help, because the information still seems inconsistent to me. (Sorry.)

No, I actually think you got it!

I suggest we change the name method to talk or speak in the Pet trait. The implementations can then be something like

impl Pet for Cat {
    fn speak(&self) -> String {
        String::from("Miau!")
    }
}

impl Pet for Dog {
    fn speak(&self) -> String {
        format!("Woof, my name is {}!", self.name);
    }
}

That would remove the name ambiguity. We should then also write notes to explain each part of the diagram.

Originally posted by @mgeisler in #1270 (reply in thread)

@mgeisler mgeisler added bug Something isn't working good first issue Good for newcomers help wanted Extra attention is needed labels Oct 3, 2023
mgeisler added a commit that referenced this issue Oct 3, 2023
The `name` struct field was confusing because it was named the same as
the trait method.

This should clean things up a little. I also compressed the code a bit
to make the unimportant structs take up less space.

Fixes #1292.
mgeisler added a commit that referenced this issue Oct 4, 2023
The `name` struct field was confusing because it was named the same as
the trait method. The struct fields are now disjoint from the method
names — the fact that there are two separate name spaces is not the
point of these slides.

I also dropped the zero-sized type, this is also not the main focus
here.

I also compressed the code a bit to make the unimportant structs take
up less space.

Fixes #1292.
mgeisler added a commit that referenced this issue Oct 4, 2023
The `name` struct field was confusing because it was named the same as
the trait method. The struct fields are now disjoint from the method
names — the fact that there are two separate name spaces is not the
point of these slides.

I also dropped the zero-sized type, this is also not the main focus
here.

I also compressed the code a bit to make the unimportant structs take
up less space.

Fixes #1292.
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
bug Something isn't working good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant