Added macro for implementing conversion traits on structs that wrap three-rs types.

[sunjay]

This macro makes it really easy for structs that simply wrap a three-rs type to implement the right traits so that those custom types can interop with three-rs methods really easily.

The macro is nice and flexible and the field name is optional. I chose the syntax MyStruct#field because it seemed more natural to me than MyStruct.field or MyStruct::field (since x::y is usually for modules or methods, not fields).

See the effect of this change here

Really wanted to replace macros in src/scene.rs with some macros that could be used outside of the crate, but unfortunately that didn't workout because while internal three objects have access to the node field, structs external to the crate do not. This causes problems in as_ref and if that one was going to deviate, we might as well make a single macro for the special purpose of classes that wrap three-rs objects.

[sunjay]

In case you're curious, my original attempt which would have been able to replace the macros in src/scene.rs is below.

The problem is in AsRef. Just &self.$field causes problems outside of this crate. Specifically, for my project, I get the error:

error[E0308]: mismatched types
--> src/player.rs:11:1
|
11 | three_as_ref_node_pointer!(Player#group);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `froggy::Pointer`, found struct `three::Group`
|
= note: expected type `&froggy::Pointer<three::Node>`
found type `&three::Group`
= note: this error originates in a macro outside of the current crate

In the macro I implemented for this PR, I had to use &self.$field.as_ref() in order for it to work outside of this crate.

/// Implement `AsRef<NodePointer>` for a given type./// Useful for when you wrap a three-rs type with your own struct. Allows you to/// use that struct in place of any three-rs object.////// ```/// // Implements AsRef<NodePointer> for MyStruct using field `internal_three_type`/// three_as_ref_node_pointer!(MyStruct#internal_three_type);/// // If field is omitted, it defaults to `node`/// three_as_ref_node_pointer!(MyStruct); // equivalent to three_as_ref_node_pointer!(MyStruct#node);/// ```#[macro_export]macro_rules! three_as_ref_node_pointer {($($name:ident),*) => {
three_as_ref_node_pointer!($($name#node),*);};($($name:ident # $field:ident),*) => {
$(implAsRef<$crate::NodePointer> for $name {fn as_ref(&self) -> &$crate::NodePointer{&self.$field
}})*};}/// Implement `Deref<Target=Object>` and `DerefMut<Object>` for a given type./// Useful for when you wrap a three-rs type with your own struct. Allows you to/// use that struct in place of any three-rs object.////// ```/// // Implements Deref<Target=Object> and DerefMut<Object> for MyStruct using field/// // `internal_three_type`/// three_deref_object!(MyStruct#internal_three_type);/// // If field is omitted, it defaults to `object`/// three_deref_object!(MyStruct); // equivalent to three_deref_object!(MyStruct#object);/// ```#[macro_export]macro_rules! three_deref_object {($($name:ident),*) => {
three_deref_object!($($name#object),*);};($($name:ident # $field:ident),*) => {
$(impl::std::ops::Dereffor $name {typeTarget = Object;fn deref(&self) -> &Object{&self.$field
}}impl::std::ops::DerefMutfor $name {fn deref_mut(&mutself) -> &mutObject{&mutself.$field
}})*};}

[sunjay]

Looks great in the docs!

Detailed docs:

[vitvakatu]

Replace this line with

```rust,no_run

to prevent running this as doc test (causes error during Travis CI)

[kvark]

This is a very well made PR, thank you!
You included extensive info on the reasoning, great comments, structure, and even provided the doc screenshots, very nice!

[kvark]

I'm unsure about including "three_" as a macro prefix. Do you see it as an established convention anywhere?

Edit: nevermind, it is the convention, all good!

[sunjay]

I don't think it is. The reason I added it is because it's nice to know where macros come from. If you look at the code where I used this (linked in the PR), it's very clear that the macro being used is for this library and its types.

I'm open to another name too if you have something in mind. :)

[kvark]

Another thing that bothers me a bit is the use of #: while it looks ok in the code, it's not near any existing convention (as you mentioned, . or ::). I think ::, while used for methods, is really straightforward here, given that C++ has it for fields as well.

[sunjay]

@vitvakatu@kvark I changed # to :: and added ignore to the doctest since getting it to compile with no_run was quite a bit of extra work. Adding a doctest for this would be great future work!

Let me know if you have any comments. If not, this should be good to go!

[kvark]

Thank you! bors r+

…

On Jun 24, 2017, at 10:58, Sunjay Varma ***@***.***> wrote: @vitvakatu@kvark I changed # to :: and added ignore to the doctest since getting it to compile with no_run was quite a bit of extra work. Adding a doctest for this would be great future work! Let me know if you have any comments. If not, this should be good to go! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[bors]

Build succeeded

• continuous-integration/travis-ci/push

[sunjay]

This macro makes it really easy for structs that simply wrap a three-rs type to implement the right traits so that those custom types can interop with three-rs methods really easily.

The macro is nice and flexible and the field name is optional. I chose the syntax MyStruct#field because it seemed more natural to me than MyStruct.field or MyStruct::field (since x::y is usually for modules or methods, not fields).

See the effect of this change here

Really wanted to replace macros in src/scene.rs with some macros that could be used outside of the crate, but unfortunately that didn't workout because while internal three objects have access to the node field, structs external to the crate do not. This causes problems in as_ref and if that one was going to deviate, we might as well make a single macro for the special purpose of classes that wrap three-rs objects.

[sunjay]

In case you're curious, my original attempt which would have been able to replace the macros in src/scene.rs is below.

The problem is in AsRef. Just &self.$field causes problems outside of this crate. Specifically, for my project, I get the error:

error[E0308]: mismatched types
--> src/player.rs:11:1
|
11 | three_as_ref_node_pointer!(Player#group);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `froggy::Pointer`, found struct `three::Group`
|
= note: expected type `&froggy::Pointer<three::Node>`
found type `&three::Group`
= note: this error originates in a macro outside of the current crate

In the macro I implemented for this PR, I had to use &self.$field.as_ref() in order for it to work outside of this crate.

/// Implement `AsRef<NodePointer>` for a given type./// Useful for when you wrap a three-rs type with your own struct. Allows you to/// use that struct in place of any three-rs object.////// ```/// // Implements AsRef<NodePointer> for MyStruct using field `internal_three_type`/// three_as_ref_node_pointer!(MyStruct#internal_three_type);/// // If field is omitted, it defaults to `node`/// three_as_ref_node_pointer!(MyStruct); // equivalent to three_as_ref_node_pointer!(MyStruct#node);/// ```#[macro_export]macro_rules! three_as_ref_node_pointer {($($name:ident),*) => {
three_as_ref_node_pointer!($($name#node),*);};($($name:ident # $field:ident),*) => {
$(implAsRef<$crate::NodePointer> for $name {fn as_ref(&self) -> &$crate::NodePointer{&self.$field
}})*};}/// Implement `Deref<Target=Object>` and `DerefMut<Object>` for a given type./// Useful for when you wrap a three-rs type with your own struct. Allows you to/// use that struct in place of any three-rs object.////// ```/// // Implements Deref<Target=Object> and DerefMut<Object> for MyStruct using field/// // `internal_three_type`/// three_deref_object!(MyStruct#internal_three_type);/// // If field is omitted, it defaults to `object`/// three_deref_object!(MyStruct); // equivalent to three_deref_object!(MyStruct#object);/// ```#[macro_export]macro_rules! three_deref_object {($($name:ident),*) => {
three_deref_object!($($name#object),*);};($($name:ident # $field:ident),*) => {
$(impl::std::ops::Dereffor $name {typeTarget = Object;fn deref(&self) -> &Object{&self.$field
}}impl::std::ops::DerefMutfor $name {fn deref_mut(&mutself) -> &mutObject{&mutself.$field
}})*};}

[sunjay]

Looks great in the docs!

Detailed docs:

[vitvakatu]

Replace this line with

```rust,no_run

to prevent running this as doc test (causes error during Travis CI)

[kvark]

This is a very well made PR, thank you!
You included extensive info on the reasoning, great comments, structure, and even provided the doc screenshots, very nice!

[kvark]

I'm unsure about including "three_" as a macro prefix. Do you see it as an established convention anywhere?

Edit: nevermind, it is the convention, all good!

[sunjay]

I don't think it is. The reason I added it is because it's nice to know where macros come from. If you look at the code where I used this (linked in the PR), it's very clear that the macro being used is for this library and its types.

I'm open to another name too if you have something in mind. :)

[kvark]

Another thing that bothers me a bit is the use of #: while it looks ok in the code, it's not near any existing convention (as you mentioned, . or ::). I think ::, while used for methods, is really straightforward here, given that C++ has it for fields as well.

[sunjay]

@vitvakatu@kvark I changed # to :: and added ignore to the doctest since getting it to compile with no_run was quite a bit of extra work. Adding a doctest for this would be great future work!

Let me know if you have any comments. If not, this should be good to go!

[kvark]

Thank you! bors r+

…

On Jun 24, 2017, at 10:58, Sunjay Varma ***@***.***> wrote: @vitvakatu@kvark I changed # to :: and added ignore to the doctest since getting it to compile with no_run was quite a bit of extra work. Adding a doctest for this would be great future work! Let me know if you have any comments. If not, this should be good to go! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[bors]

Build succeeded

• continuous-integration/travis-ci/push

[sunjay]

This macro makes it really easy for structs that simply wrap a three-rs type to implement the right traits so that those custom types can interop with three-rs methods really easily.

The macro is nice and flexible and the field name is optional. I chose the syntax MyStruct#field because it seemed more natural to me than MyStruct.field or MyStruct::field (since x::y is usually for modules or methods, not fields).

See the effect of this change here

Really wanted to replace macros in src/scene.rs with some macros that could be used outside of the crate, but unfortunately that didn't workout because while internal three objects have access to the node field, structs external to the crate do not. This causes problems in as_ref and if that one was going to deviate, we might as well make a single macro for the special purpose of classes that wrap three-rs objects.

[sunjay]

In case you're curious, my original attempt which would have been able to replace the macros in src/scene.rs is below.

The problem is in AsRef. Just &self.$field causes problems outside of this crate. Specifically, for my project, I get the error:

error[E0308]: mismatched types
--> src/player.rs:11:1
|
11 | three_as_ref_node_pointer!(Player#group);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `froggy::Pointer`, found struct `three::Group`
|
= note: expected type `&froggy::Pointer<three::Node>`
found type `&three::Group`
= note: this error originates in a macro outside of the current crate

In the macro I implemented for this PR, I had to use &self.$field.as_ref() in order for it to work outside of this crate.

/// Implement `AsRef<NodePointer>` for a given type./// Useful for when you wrap a three-rs type with your own struct. Allows you to/// use that struct in place of any three-rs object.////// ```/// // Implements AsRef<NodePointer> for MyStruct using field `internal_three_type`/// three_as_ref_node_pointer!(MyStruct#internal_three_type);/// // If field is omitted, it defaults to `node`/// three_as_ref_node_pointer!(MyStruct); // equivalent to three_as_ref_node_pointer!(MyStruct#node);/// ```#[macro_export]macro_rules! three_as_ref_node_pointer {($($name:ident),*) => {
three_as_ref_node_pointer!($($name#node),*);};($($name:ident # $field:ident),*) => {
$(implAsRef<$crate::NodePointer> for $name {fn as_ref(&self) -> &$crate::NodePointer{&self.$field
}})*};}/// Implement `Deref<Target=Object>` and `DerefMut<Object>` for a given type./// Useful for when you wrap a three-rs type with your own struct. Allows you to/// use that struct in place of any three-rs object.////// ```/// // Implements Deref<Target=Object> and DerefMut<Object> for MyStruct using field/// // `internal_three_type`/// three_deref_object!(MyStruct#internal_three_type);/// // If field is omitted, it defaults to `object`/// three_deref_object!(MyStruct); // equivalent to three_deref_object!(MyStruct#object);/// ```#[macro_export]macro_rules! three_deref_object {($($name:ident),*) => {
three_deref_object!($($name#object),*);};($($name:ident # $field:ident),*) => {
$(impl::std::ops::Dereffor $name {typeTarget = Object;fn deref(&self) -> &Object{&self.$field
}}impl::std::ops::DerefMutfor $name {fn deref_mut(&mutself) -> &mutObject{&mutself.$field
}})*};}

[sunjay]

Looks great in the docs!

Detailed docs:

[vitvakatu]

Replace this line with

```rust,no_run

to prevent running this as doc test (causes error during Travis CI)

[kvark]

This is a very well made PR, thank you!
You included extensive info on the reasoning, great comments, structure, and even provided the doc screenshots, very nice!

[kvark]

I'm unsure about including "three_" as a macro prefix. Do you see it as an established convention anywhere?

Edit: nevermind, it is the convention, all good!

[sunjay]

I don't think it is. The reason I added it is because it's nice to know where macros come from. If you look at the code where I used this (linked in the PR), it's very clear that the macro being used is for this library and its types.

I'm open to another name too if you have something in mind. :)

[kvark]

Another thing that bothers me a bit is the use of #: while it looks ok in the code, it's not near any existing convention (as you mentioned, . or ::). I think ::, while used for methods, is really straightforward here, given that C++ has it for fields as well.

[sunjay]

@vitvakatu@kvark I changed # to :: and added ignore to the doctest since getting it to compile with no_run was quite a bit of extra work. Adding a doctest for this would be great future work!

Let me know if you have any comments. If not, this should be good to go!

[kvark]

Thank you! bors r+

…

On Jun 24, 2017, at 10:58, Sunjay Varma ***@***.***> wrote: @vitvakatu@kvark I changed # to :: and added ignore to the doctest since getting it to compile with no_run was quite a bit of extra work. Adding a doctest for this would be great future work! Let me know if you have any comments. If not, this should be good to go! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[bors]

Build succeeded

• continuous-integration/travis-ci/push

[sunjay]

This macro makes it really easy for structs that simply wrap a three-rs type to implement the right traits so that those custom types can interop with three-rs methods really easily.

The macro is nice and flexible and the field name is optional. I chose the syntax MyStruct#field because it seemed more natural to me than MyStruct.field or MyStruct::field (since x::y is usually for modules or methods, not fields).

See the effect of this change here

Really wanted to replace macros in src/scene.rs with some macros that could be used outside of the crate, but unfortunately that didn't workout because while internal three objects have access to the node field, structs external to the crate do not. This causes problems in as_ref and if that one was going to deviate, we might as well make a single macro for the special purpose of classes that wrap three-rs objects.

[sunjay]

In case you're curious, my original attempt which would have been able to replace the macros in src/scene.rs is below.

The problem is in AsRef. Just &self.$field causes problems outside of this crate. Specifically, for my project, I get the error:

error[E0308]: mismatched types
--> src/player.rs:11:1
|
11 | three_as_ref_node_pointer!(Player#group);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `froggy::Pointer`, found struct `three::Group`
|
= note: expected type `&froggy::Pointer<three::Node>`
found type `&three::Group`
= note: this error originates in a macro outside of the current crate

In the macro I implemented for this PR, I had to use &self.$field.as_ref() in order for it to work outside of this crate.

/// Implement `AsRef<NodePointer>` for a given type./// Useful for when you wrap a three-rs type with your own struct. Allows you to/// use that struct in place of any three-rs object.////// ```/// // Implements AsRef<NodePointer> for MyStruct using field `internal_three_type`/// three_as_ref_node_pointer!(MyStruct#internal_three_type);/// // If field is omitted, it defaults to `node`/// three_as_ref_node_pointer!(MyStruct); // equivalent to three_as_ref_node_pointer!(MyStruct#node);/// ```#[macro_export]macro_rules! three_as_ref_node_pointer {($($name:ident),*) => {
three_as_ref_node_pointer!($($name#node),*);};($($name:ident # $field:ident),*) => {
$(implAsRef<$crate::NodePointer> for $name {fn as_ref(&self) -> &$crate::NodePointer{&self.$field
}})*};}/// Implement `Deref<Target=Object>` and `DerefMut<Object>` for a given type./// Useful for when you wrap a three-rs type with your own struct. Allows you to/// use that struct in place of any three-rs object.////// ```/// // Implements Deref<Target=Object> and DerefMut<Object> for MyStruct using field/// // `internal_three_type`/// three_deref_object!(MyStruct#internal_three_type);/// // If field is omitted, it defaults to `object`/// three_deref_object!(MyStruct); // equivalent to three_deref_object!(MyStruct#object);/// ```#[macro_export]macro_rules! three_deref_object {($($name:ident),*) => {
three_deref_object!($($name#object),*);};($($name:ident # $field:ident),*) => {
$(impl::std::ops::Dereffor $name {typeTarget = Object;fn deref(&self) -> &Object{&self.$field
}}impl::std::ops::DerefMutfor $name {fn deref_mut(&mutself) -> &mutObject{&mutself.$field
}})*};}

[sunjay]

Looks great in the docs!

Detailed docs:

[vitvakatu]

Replace this line with

```rust,no_run

to prevent running this as doc test (causes error during Travis CI)

[kvark]

This is a very well made PR, thank you!
You included extensive info on the reasoning, great comments, structure, and even provided the doc screenshots, very nice!

[kvark]

I'm unsure about including "three_" as a macro prefix. Do you see it as an established convention anywhere?

Edit: nevermind, it is the convention, all good!

[sunjay]

I don't think it is. The reason I added it is because it's nice to know where macros come from. If you look at the code where I used this (linked in the PR), it's very clear that the macro being used is for this library and its types.

I'm open to another name too if you have something in mind. :)

[kvark]

Another thing that bothers me a bit is the use of #: while it looks ok in the code, it's not near any existing convention (as you mentioned, . or ::). I think ::, while used for methods, is really straightforward here, given that C++ has it for fields as well.

[sunjay]

@vitvakatu@kvark I changed # to :: and added ignore to the doctest since getting it to compile with no_run was quite a bit of extra work. Adding a doctest for this would be great future work!

Let me know if you have any comments. If not, this should be good to go!

[kvark]

Thank you! bors r+

…

On Jun 24, 2017, at 10:58, Sunjay Varma ***@***.***> wrote: @vitvakatu@kvark I changed # to :: and added ignore to the doctest since getting it to compile with no_run was quite a bit of extra work. Adding a doctest for this would be great future work! Let me know if you have any comments. If not, this should be good to go! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[bors]

Build succeeded

• continuous-integration/travis-ci/push

[sunjay]

This macro makes it really easy for structs that simply wrap a three-rs type to implement the right traits so that those custom types can interop with three-rs methods really easily.

The macro is nice and flexible and the field name is optional. I chose the syntax MyStruct#field because it seemed more natural to me than MyStruct.field or MyStruct::field (since x::y is usually for modules or methods, not fields).

See the effect of this change here

Really wanted to replace macros in src/scene.rs with some macros that could be used outside of the crate, but unfortunately that didn't workout because while internal three objects have access to the node field, structs external to the crate do not. This causes problems in as_ref and if that one was going to deviate, we might as well make a single macro for the special purpose of classes that wrap three-rs objects.

[sunjay]

In case you're curious, my original attempt which would have been able to replace the macros in src/scene.rs is below.

The problem is in AsRef. Just &self.$field causes problems outside of this crate. Specifically, for my project, I get the error:

error[E0308]: mismatched types
--> src/player.rs:11:1
|
11 | three_as_ref_node_pointer!(Player#group);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `froggy::Pointer`, found struct `three::Group`
|
= note: expected type `&froggy::Pointer<three::Node>`
found type `&three::Group`
= note: this error originates in a macro outside of the current crate

In the macro I implemented for this PR, I had to use &self.$field.as_ref() in order for it to work outside of this crate.

/// Implement `AsRef<NodePointer>` for a given type./// Useful for when you wrap a three-rs type with your own struct. Allows you to/// use that struct in place of any three-rs object.////// ```/// // Implements AsRef<NodePointer> for MyStruct using field `internal_three_type`/// three_as_ref_node_pointer!(MyStruct#internal_three_type);/// // If field is omitted, it defaults to `node`/// three_as_ref_node_pointer!(MyStruct); // equivalent to three_as_ref_node_pointer!(MyStruct#node);/// ```#[macro_export]macro_rules! three_as_ref_node_pointer {($($name:ident),*) => {
three_as_ref_node_pointer!($($name#node),*);};($($name:ident # $field:ident),*) => {
$(implAsRef<$crate::NodePointer> for $name {fn as_ref(&self) -> &$crate::NodePointer{&self.$field
}})*};}/// Implement `Deref<Target=Object>` and `DerefMut<Object>` for a given type./// Useful for when you wrap a three-rs type with your own struct. Allows you to/// use that struct in place of any three-rs object.////// ```/// // Implements Deref<Target=Object> and DerefMut<Object> for MyStruct using field/// // `internal_three_type`/// three_deref_object!(MyStruct#internal_three_type);/// // If field is omitted, it defaults to `object`/// three_deref_object!(MyStruct); // equivalent to three_deref_object!(MyStruct#object);/// ```#[macro_export]macro_rules! three_deref_object {($($name:ident),*) => {
three_deref_object!($($name#object),*);};($($name:ident # $field:ident),*) => {
$(impl::std::ops::Dereffor $name {typeTarget = Object;fn deref(&self) -> &Object{&self.$field
}}impl::std::ops::DerefMutfor $name {fn deref_mut(&mutself) -> &mutObject{&mutself.$field
}})*};}

[sunjay]

Looks great in the docs!

Detailed docs:

[vitvakatu]

Replace this line with

```rust,no_run

to prevent running this as doc test (causes error during Travis CI)

[kvark]

This is a very well made PR, thank you!
You included extensive info on the reasoning, great comments, structure, and even provided the doc screenshots, very nice!

[kvark]

I'm unsure about including "three_" as a macro prefix. Do you see it as an established convention anywhere?

Edit: nevermind, it is the convention, all good!

[sunjay]

I don't think it is. The reason I added it is because it's nice to know where macros come from. If you look at the code where I used this (linked in the PR), it's very clear that the macro being used is for this library and its types.

I'm open to another name too if you have something in mind. :)

[kvark]

Another thing that bothers me a bit is the use of #: while it looks ok in the code, it's not near any existing convention (as you mentioned, . or ::). I think ::, while used for methods, is really straightforward here, given that C++ has it for fields as well.

[sunjay]

@vitvakatu@kvark I changed # to :: and added ignore to the doctest since getting it to compile with no_run was quite a bit of extra work. Adding a doctest for this would be great future work!

Let me know if you have any comments. If not, this should be good to go!

[kvark]

Thank you! bors r+

…

On Jun 24, 2017, at 10:58, Sunjay Varma ***@***.***> wrote: @vitvakatu@kvark I changed # to :: and added ignore to the doctest since getting it to compile with no_run was quite a bit of extra work. Adding a doctest for this would be great future work! Let me know if you have any comments. If not, this should be good to go! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[bors]

Build succeeded

• continuous-integration/travis-ci/push

[sunjay]

This macro makes it really easy for structs that simply wrap a three-rs type to implement the right traits so that those custom types can interop with three-rs methods really easily.

The macro is nice and flexible and the field name is optional. I chose the syntax MyStruct#field because it seemed more natural to me than MyStruct.field or MyStruct::field (since x::y is usually for modules or methods, not fields).

See the effect of this change here

Really wanted to replace macros in src/scene.rs with some macros that could be used outside of the crate, but unfortunately that didn't workout because while internal three objects have access to the node field, structs external to the crate do not. This causes problems in as_ref and if that one was going to deviate, we might as well make a single macro for the special purpose of classes that wrap three-rs objects.

[sunjay]

In case you're curious, my original attempt which would have been able to replace the macros in src/scene.rs is below.

The problem is in AsRef. Just &self.$field causes problems outside of this crate. Specifically, for my project, I get the error:

error[E0308]: mismatched types
--> src/player.rs:11:1
|
11 | three_as_ref_node_pointer!(Player#group);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `froggy::Pointer`, found struct `three::Group`
|
= note: expected type `&froggy::Pointer<three::Node>`
found type `&three::Group`
= note: this error originates in a macro outside of the current crate

In the macro I implemented for this PR, I had to use &self.$field.as_ref() in order for it to work outside of this crate.

/// Implement `AsRef<NodePointer>` for a given type./// Useful for when you wrap a three-rs type with your own struct. Allows you to/// use that struct in place of any three-rs object.////// ```/// // Implements AsRef<NodePointer> for MyStruct using field `internal_three_type`/// three_as_ref_node_pointer!(MyStruct#internal_three_type);/// // If field is omitted, it defaults to `node`/// three_as_ref_node_pointer!(MyStruct); // equivalent to three_as_ref_node_pointer!(MyStruct#node);/// ```#[macro_export]macro_rules! three_as_ref_node_pointer {($($name:ident),*) => {
three_as_ref_node_pointer!($($name#node),*);};($($name:ident # $field:ident),*) => {
$(implAsRef<$crate::NodePointer> for $name {fn as_ref(&self) -> &$crate::NodePointer{&self.$field
}})*};}/// Implement `Deref<Target=Object>` and `DerefMut<Object>` for a given type./// Useful for when you wrap a three-rs type with your own struct. Allows you to/// use that struct in place of any three-rs object.////// ```/// // Implements Deref<Target=Object> and DerefMut<Object> for MyStruct using field/// // `internal_three_type`/// three_deref_object!(MyStruct#internal_three_type);/// // If field is omitted, it defaults to `object`/// three_deref_object!(MyStruct); // equivalent to three_deref_object!(MyStruct#object);/// ```#[macro_export]macro_rules! three_deref_object {($($name:ident),*) => {
three_deref_object!($($name#object),*);};($($name:ident # $field:ident),*) => {
$(impl::std::ops::Dereffor $name {typeTarget = Object;fn deref(&self) -> &Object{&self.$field
}}impl::std::ops::DerefMutfor $name {fn deref_mut(&mutself) -> &mutObject{&mutself.$field
}})*};}

[sunjay]

Looks great in the docs!

Detailed docs:

[vitvakatu]

Replace this line with

```rust,no_run

to prevent running this as doc test (causes error during Travis CI)

[kvark]

This is a very well made PR, thank you!
You included extensive info on the reasoning, great comments, structure, and even provided the doc screenshots, very nice!

[kvark]

I'm unsure about including "three_" as a macro prefix. Do you see it as an established convention anywhere?

Edit: nevermind, it is the convention, all good!

[sunjay]

I don't think it is. The reason I added it is because it's nice to know where macros come from. If you look at the code where I used this (linked in the PR), it's very clear that the macro being used is for this library and its types.

I'm open to another name too if you have something in mind. :)

[kvark]

Another thing that bothers me a bit is the use of #: while it looks ok in the code, it's not near any existing convention (as you mentioned, . or ::). I think ::, while used for methods, is really straightforward here, given that C++ has it for fields as well.

[sunjay]

@vitvakatu@kvark I changed # to :: and added ignore to the doctest since getting it to compile with no_run was quite a bit of extra work. Adding a doctest for this would be great future work!

Let me know if you have any comments. If not, this should be good to go!

[kvark]

Thank you! bors r+

…

On Jun 24, 2017, at 10:58, Sunjay Varma ***@***.***> wrote: @vitvakatu@kvark I changed # to :: and added ignore to the doctest since getting it to compile with no_run was quite a bit of extra work. Adding a doctest for this would be great future work! Let me know if you have any comments. If not, this should be good to go! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[bors]

Build succeeded

• continuous-integration/travis-ci/push

[sunjay]

This macro makes it really easy for structs that simply wrap a three-rs type to implement the right traits so that those custom types can interop with three-rs methods really easily.

The macro is nice and flexible and the field name is optional. I chose the syntax MyStruct#field because it seemed more natural to me than MyStruct.field or MyStruct::field (since x::y is usually for modules or methods, not fields).

See the effect of this change here

Really wanted to replace macros in src/scene.rs with some macros that could be used outside of the crate, but unfortunately that didn't workout because while internal three objects have access to the node field, structs external to the crate do not. This causes problems in as_ref and if that one was going to deviate, we might as well make a single macro for the special purpose of classes that wrap three-rs objects.

[sunjay]

In case you're curious, my original attempt which would have been able to replace the macros in src/scene.rs is below.

The problem is in AsRef. Just &self.$field causes problems outside of this crate. Specifically, for my project, I get the error:

error[E0308]: mismatched types
--> src/player.rs:11:1
|
11 | three_as_ref_node_pointer!(Player#group);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `froggy::Pointer`, found struct `three::Group`
|
= note: expected type `&froggy::Pointer<three::Node>`
found type `&three::Group`
= note: this error originates in a macro outside of the current crate

In the macro I implemented for this PR, I had to use &self.$field.as_ref() in order for it to work outside of this crate.

/// Implement `AsRef<NodePointer>` for a given type./// Useful for when you wrap a three-rs type with your own struct. Allows you to/// use that struct in place of any three-rs object.////// ```/// // Implements AsRef<NodePointer> for MyStruct using field `internal_three_type`/// three_as_ref_node_pointer!(MyStruct#internal_three_type);/// // If field is omitted, it defaults to `node`/// three_as_ref_node_pointer!(MyStruct); // equivalent to three_as_ref_node_pointer!(MyStruct#node);/// ```#[macro_export]macro_rules! three_as_ref_node_pointer {($($name:ident),*) => {
three_as_ref_node_pointer!($($name#node),*);};($($name:ident # $field:ident),*) => {
$(implAsRef<$crate::NodePointer> for $name {fn as_ref(&self) -> &$crate::NodePointer{&self.$field
}})*};}/// Implement `Deref<Target=Object>` and `DerefMut<Object>` for a given type./// Useful for when you wrap a three-rs type with your own struct. Allows you to/// use that struct in place of any three-rs object.////// ```/// // Implements Deref<Target=Object> and DerefMut<Object> for MyStruct using field/// // `internal_three_type`/// three_deref_object!(MyStruct#internal_three_type);/// // If field is omitted, it defaults to `object`/// three_deref_object!(MyStruct); // equivalent to three_deref_object!(MyStruct#object);/// ```#[macro_export]macro_rules! three_deref_object {($($name:ident),*) => {
three_deref_object!($($name#object),*);};($($name:ident # $field:ident),*) => {
$(impl::std::ops::Dereffor $name {typeTarget = Object;fn deref(&self) -> &Object{&self.$field
}}impl::std::ops::DerefMutfor $name {fn deref_mut(&mutself) -> &mutObject{&mutself.$field
}})*};}

[sunjay]

Looks great in the docs!

Detailed docs:

[vitvakatu]

Replace this line with

```rust,no_run

to prevent running this as doc test (causes error during Travis CI)

[kvark]

This is a very well made PR, thank you!
You included extensive info on the reasoning, great comments, structure, and even provided the doc screenshots, very nice!

[kvark]

I'm unsure about including "three_" as a macro prefix. Do you see it as an established convention anywhere?

Edit: nevermind, it is the convention, all good!

[sunjay]

I don't think it is. The reason I added it is because it's nice to know where macros come from. If you look at the code where I used this (linked in the PR), it's very clear that the macro being used is for this library and its types.

I'm open to another name too if you have something in mind. :)

[kvark]

Another thing that bothers me a bit is the use of #: while it looks ok in the code, it's not near any existing convention (as you mentioned, . or ::). I think ::, while used for methods, is really straightforward here, given that C++ has it for fields as well.

[sunjay]

@vitvakatu@kvark I changed # to :: and added ignore to the doctest since getting it to compile with no_run was quite a bit of extra work. Adding a doctest for this would be great future work!

Let me know if you have any comments. If not, this should be good to go!

[kvark]

Thank you! bors r+

…

On Jun 24, 2017, at 10:58, Sunjay Varma ***@***.***> wrote: @vitvakatu@kvark I changed # to :: and added ignore to the doctest since getting it to compile with no_run was quite a bit of extra work. Adding a doctest for this would be great future work! Let me know if you have any comments. If not, this should be good to go! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[bors]

Build succeeded

• continuous-integration/travis-ci/push

[sunjay]

This macro makes it really easy for structs that simply wrap a three-rs type to implement the right traits so that those custom types can interop with three-rs methods really easily.

The macro is nice and flexible and the field name is optional. I chose the syntax MyStruct#field because it seemed more natural to me than MyStruct.field or MyStruct::field (since x::y is usually for modules or methods, not fields).

See the effect of this change here

Really wanted to replace macros in src/scene.rs with some macros that could be used outside of the crate, but unfortunately that didn't workout because while internal three objects have access to the node field, structs external to the crate do not. This causes problems in as_ref and if that one was going to deviate, we might as well make a single macro for the special purpose of classes that wrap three-rs objects.

[sunjay]

In case you're curious, my original attempt which would have been able to replace the macros in src/scene.rs is below.

The problem is in AsRef. Just &self.$field causes problems outside of this crate. Specifically, for my project, I get the error:

error[E0308]: mismatched types
--> src/player.rs:11:1
|
11 | three_as_ref_node_pointer!(Player#group);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `froggy::Pointer`, found struct `three::Group`
|
= note: expected type `&froggy::Pointer<three::Node>`
found type `&three::Group`
= note: this error originates in a macro outside of the current crate

In the macro I implemented for this PR, I had to use &self.$field.as_ref() in order for it to work outside of this crate.

/// Implement `AsRef<NodePointer>` for a given type./// Useful for when you wrap a three-rs type with your own struct. Allows you to/// use that struct in place of any three-rs object.////// ```/// // Implements AsRef<NodePointer> for MyStruct using field `internal_three_type`/// three_as_ref_node_pointer!(MyStruct#internal_three_type);/// // If field is omitted, it defaults to `node`/// three_as_ref_node_pointer!(MyStruct); // equivalent to three_as_ref_node_pointer!(MyStruct#node);/// ```#[macro_export]macro_rules! three_as_ref_node_pointer {($($name:ident),*) => {
three_as_ref_node_pointer!($($name#node),*);};($($name:ident # $field:ident),*) => {
$(implAsRef<$crate::NodePointer> for $name {fn as_ref(&self) -> &$crate::NodePointer{&self.$field
}})*};}/// Implement `Deref<Target=Object>` and `DerefMut<Object>` for a given type./// Useful for when you wrap a three-rs type with your own struct. Allows you to/// use that struct in place of any three-rs object.////// ```/// // Implements Deref<Target=Object> and DerefMut<Object> for MyStruct using field/// // `internal_three_type`/// three_deref_object!(MyStruct#internal_three_type);/// // If field is omitted, it defaults to `object`/// three_deref_object!(MyStruct); // equivalent to three_deref_object!(MyStruct#object);/// ```#[macro_export]macro_rules! three_deref_object {($($name:ident),*) => {
three_deref_object!($($name#object),*);};($($name:ident # $field:ident),*) => {
$(impl::std::ops::Dereffor $name {typeTarget = Object;fn deref(&self) -> &Object{&self.$field
}}impl::std::ops::DerefMutfor $name {fn deref_mut(&mutself) -> &mutObject{&mutself.$field
}})*};}

[sunjay]

Looks great in the docs!

Detailed docs:

[vitvakatu]

Replace this line with

```rust,no_run

to prevent running this as doc test (causes error during Travis CI)

[kvark]

This is a very well made PR, thank you!
You included extensive info on the reasoning, great comments, structure, and even provided the doc screenshots, very nice!

[kvark]

I'm unsure about including "three_" as a macro prefix. Do you see it as an established convention anywhere?

Edit: nevermind, it is the convention, all good!

[sunjay]

I don't think it is. The reason I added it is because it's nice to know where macros come from. If you look at the code where I used this (linked in the PR), it's very clear that the macro being used is for this library and its types.

I'm open to another name too if you have something in mind. :)

[kvark]

Another thing that bothers me a bit is the use of #: while it looks ok in the code, it's not near any existing convention (as you mentioned, . or ::). I think ::, while used for methods, is really straightforward here, given that C++ has it for fields as well.

[sunjay]

@vitvakatu@kvark I changed # to :: and added ignore to the doctest since getting it to compile with no_run was quite a bit of extra work. Adding a doctest for this would be great future work!

Let me know if you have any comments. If not, this should be good to go!

[kvark]

Thank you! bors r+

…

On Jun 24, 2017, at 10:58, Sunjay Varma ***@***.***> wrote: @vitvakatu@kvark I changed # to :: and added ignore to the doctest since getting it to compile with no_run was quite a bit of extra work. Adding a doctest for this would be great future work! Let me know if you have any comments. If not, this should be good to go! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[bors]

Build succeeded

• continuous-integration/travis-ci/push