iamcsharper / bullet-xna

Automatically exported from code.google.com/p/bullet-xna
0 stars 0 forks source link

Remove using System.Linq; #7

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
This is fairly low in importance, however, there doesn't seem to be anything 
using System.Linq in BulletXNA.  By default, it's added to the usings when the 
class is created in visual studio even when it's not necessary.  Suggest 
removing them where appropriate.

Original issue reported on code.google.com by dcoliva...@gmail.com on 2 Jun 2011 at 5:16

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
Removed that one too. Thanks!

Original comment by andres.traks on 11 Jun 2011 at 8:19