New issue

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

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

Already on GitHub? Sign in to your account

PolyLine should accept closed at initialization #1412

Merged
merged 1 commit into from Oct 21, 2016

Conversation

Projects
None yet
4 participants
@drewish
Contributor

drewish commented Apr 2, 2016

This let's me simplify some code like:

ci::PolyLine2f BuildingPlan::triangle()
{
    ci::PolyLine2f result( { ci::vec2(10, -10), ci::vec2(10, 10), ci::vec2(-10, 10), ci::vec2(10, -10)  } );
    result.setClosed();
    return result;
}

Down to a one liner.

ci::PolyLine2f BuildingPlan::triangle()
{
    return ci::PolyLine2f( { ci::vec2(10, -10), ci::vec2(10, 10), ci::vec2(-10, 10), ci::vec2(10, -10)  }, true );
}
@mottosso

This comment has been minimized.

Show comment
Hide comment
@mottosso

mottosso Apr 3, 2016

I personally really like the named parameter idiom spread across Cinder. Could that work here?

ci::PolyLine2f BuildingPlan::triangle()
{
    return ci::PolyLine2f( { ci::vec2(10, -10), ci::vec2(10, 10), ci::vec2(-10, 10), ci::vec2(10, -10)  } ).closed(true);
}

Though it should probably apply to the other arguments too.

mottosso commented Apr 3, 2016

I personally really like the named parameter idiom spread across Cinder. Could that work here?

ci::PolyLine2f BuildingPlan::triangle()
{
    return ci::PolyLine2f( { ci::vec2(10, -10), ci::vec2(10, 10), ci::vec2(-10, 10), ci::vec2(10, -10)  } ).closed(true);
}

Though it should probably apply to the other arguments too.

@drewish

This comment has been minimized.

Show comment
Hide comment
@drewish

drewish Apr 3, 2016

Contributor

@mottosso yeah that's actually a nice pattern to follow, and it'd be backwards compatible if we left the other methods in place.

Edit: I think it's make sense to define closed with a default param of true so you could just do closed() or closed(false)

Contributor

drewish commented Apr 3, 2016

@mottosso yeah that's actually a nice pattern to follow, and it'd be backwards compatible if we left the other methods in place.

Edit: I think it's make sense to define closed with a default param of true so you could just do closed() or closed(false)

@richardeakin

This comment has been minimized.

Show comment
Hide comment
@richardeakin

richardeakin Apr 4, 2016

Collaborator

I also prefer a named method rather than additional bool as argument, because it is clearer at the call site. That said, I don't believe the classes like Polyline, Shape2d, are currently using the named parameter idiom, not that they shouldn't but need to weigh whether we want to start introducing methods in that fashion there.

Collaborator

richardeakin commented Apr 4, 2016

I also prefer a named method rather than additional bool as argument, because it is clearer at the call site. That said, I don't believe the classes like Polyline, Shape2d, are currently using the named parameter idiom, not that they shouldn't but need to weigh whether we want to start introducing methods in that fashion there.

@andrewfb

This comment has been minimized.

Show comment
Hide comment
@andrewfb

andrewfb Oct 18, 2016

Collaborator

I'm inclined to accept this as written. I'm not opposed to NPI in instances like this, but it does feel like a policy that needs to revisited on a larger scale at some future date.

Collaborator

andrewfb commented Oct 18, 2016

I'm inclined to accept this as written. I'm not opposed to NPI in instances like this, but it does feel like a policy that needs to revisited on a larger scale at some future date.

@andrewfb andrewfb merged commit e5a28a6 into cinder:master Oct 21, 2016

@drewish drewish deleted the drewish:polyline-closed branch Oct 22, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment