Closed GoogleCodeExporter closed 9 years ago
On a related note, I'd like to remove the deep namespaces in the project (such
as BulletXNA.BulletCollision.CollisionShapes and
BulletXNA.BulletCollision.BroadphaseCollision) and keep at most the
second-level namespaces (BulletXNA.BulletCollision). There aren't any clashing
symbol names, so I think it makes sense. This also avoids having to write 6-7
"using" statements to include parts of the library which you'd normally have to
include anyway.
I've already done this in the no-xna branch, but what do you guys think?
Original comment by andres.traks
on 2 Jun 2011 at 6:33
I'm very slightly leaning +1 that idea. I understand why that would be
beneficial... making it more 'turnkey' for the average .NET user.
It also gets around the 'creating our own documentation because we diverged'
issue because people are less likely to run into it because more classes are
included in the more general usings.
The two counter arguments are:
1. We have to be sure that the class names in the namespaces do not overlap
/ever/ even if they /ever/ do in Bullet
2. Just the general fact that we're diverging here can be dangerous/make
maintaining slightly more difficult.
Original comment by dcoliva...@gmail.com
on 2 Jun 2011 at 7:43
I went ahead and cleaned up the namespaces and removed the Linq dependency in
r62.
I wouldn't say we're diverging, because the organization of source code files
and the organization of the namespace (public API) can be different things.
Original comment by andres.traks
on 10 Jun 2011 at 5:17
Linq is still in BulletCollision\GImpact\BoxCollision.cs
Other then that, this is resolved.
That is all
Original comment by dcoliva...@gmail.com
on 11 Jun 2011 at 7:17
Removed that one too. Thanks!
Original comment by andres.traks
on 11 Jun 2011 at 8:19
Original issue reported on code.google.com by
dcoliva...@gmail.com
on 2 Jun 2011 at 5:16