The semantics of alignBL and snugBL may not be what we want.

[jeffreyrosenbluth]

snugBL = snugB . snugL, Unfortunately snugB and snugL do not commute so their
behavior is different, i.e snugBL /= snugL. snugB. This can lead to results that may not be
intuitive (or useful) to users.

snugBL

snugB . snugL

At least alignB and alignL commute, but still it seems strange that alignBL puts the origin outside of
the hexagon. Whereas if we align in the (-1,-1) direction we end up on the hexagon.
align ((-1) ^& (-1))

alignBL

One possible solution is to redefine both alignBL and snugBL as align ((-1) ^& (-1)) ...

thoughts?

[cchalmers]

Yeah, the current snugBL doesn't make much sense. Maybe snugSW like you mentioned on irc could work but I'm still not sure how useful it would be.

I'm against changed alignBL and friends, it's very useful for getting this into a corner:

Maybe alignSW could be used for this too if you want it.

[bergey]

I'd like to keep the current semantics of alignBL. I'm fine adding alignSW. I have no opinion about the snug versions.

[jeffreyrosenbluth]

Ok, so we keep alignBL as is.
I'm starting to think we should simply deprecate snugBL and the like.
By the way how should we go about deprecating a function.

[cchalmers]

I'd be happy with that.

[byorgey]

Agree on keeping alignBL the way it is. I would also be find deprecating
snugBL and the like. I assume we already have a version of snug that can
take an arbitrary direction as a parameter?

On Wed, May 6, 2015 at 9:47 AM Chris notifications@github.com wrote:

I'd be happy with that.

—
Reply to this email directly or view it on GitHub
#250 (comment)
.

[jeffreyrosenbluth]

yes we do have snug which takes an arbitrary direction as parameter.

[jeffreyrosenbluth]

To summarize:

• we leave alignBL alone
• we deprecated snugBL