4

I have two projects that contain extension methods. One project is implemented using C# and the other is implemented using VB.NET as there are some things I can do in VB.NET that I can't in C# and I want to leverage those features in my extension methods.

How can I name the projects to convey their meaning while at the same time differentiating that they are implemented in different languages?

For the C# elitists:

One of the features that VB.NET supports that C# doesn't:

Doesn't C# Extension Methods allow passing parameters by reference?

FYI: This doesn't work for reference types, which is what I'm interested in.

public static void LoadFromXml<T>(this T targetObject, string xml)
{

    targetObject = _Serializer.DeserializeFromXML<T>(xml);

}
Community
  • 1
  • 1
Achilles
  • 11,165
  • 9
  • 62
  • 113
  • 5
    Just curious... what features are you using in VB.NET that you believe you can't use in C#? Even if that were true, you could build a DLL with VB.NET and leverage it in your C# project. – Brad Jun 12 '12 at 19:46
  • It's true, VB.NET supports ByRef params on it's extension methods. http://stackoverflow.com/questions/1259103/doesnt-c-sharp-extension-methods-allow-passing-parameters-by-reference – Achilles Jun 12 '12 at 19:47
  • It all compiles to the same thing (MSIL) so there will be no difference to the user. Typically assemblies are named according the function they perform. I don't think there is going to be a clean solution, and it will be very frustrating for the user (who must remember which arbitrary assembly that particular function was in). What features are so essential that they are driving you to split your assemblies? – JDB Jun 12 '12 at 19:47
  • I agree with @Brad. For the area where you need the by ref parameters, why not just build a single assembly with a VB project and forget the C#? – Chris Farmer Jun 12 '12 at 19:50
  • 1
    @Achilles why would you want to use ByRef parameters anyway? Why not return a class with those values instead? Just a C# dev thinking out loud ... – jrummell Jun 12 '12 at 19:50
  • @jfrummell, presumably the answer is precisely the same as for why one would use `ref` in general. – Kirk Woll Jun 12 '12 at 19:53
  • 2
    Just because you can do it, doesn't mean you should. – vcsjones Jun 12 '12 at 19:54
  • @vcsjones I agree - this seems like it's typical use case is to make immutable value types appear mutable, which is just confusing and (IMO) a bad practice in general... – Reed Copsey Jun 12 '12 at 19:57
  • I was going to say the same thing as vcsjones. Just because it has byref, doesn't make it good practice to use it. I have yet to find something I could accomplish in vb.net that I couldn't accomplish in C#. – Brian Jun 12 '12 at 20:02
  • This doesn't work for reference types...that's the problem. I'm not trying to make immutable types mutate. – Achilles Jun 12 '12 at 20:13
  • Reference types are always passed by reference in C#, right? – jrummell Jun 12 '12 at 20:18
  • Nope, not into extension methods. – Achilles Jun 12 '12 at 20:20
  • 1
    @Achilles You don't have to pass a reference type by reference, unless you want to reassign it - which is something I would *cringe* at in an extension method. Passing a reference type by value still lets you modify its properties fine. – Reed Copsey Jun 12 '12 at 20:21
  • @Achilles Reference types *are* always passed by reference, even to extension methods. You are talking about a reference to a reference. – vcsjones Jun 12 '12 at 20:21
  • If I change the param's value it is not being reflected in the calling function. – Achilles Jun 12 '12 at 20:29
  • It might be helpful to include an example where you are using ByRef, so that we can see in detail the issue you are concerned about. – jrummell Jun 12 '12 at 20:32
  • That's an interesting way to use extension methods. Based on my C# experience, I would make that a regular static method. – jrummell Jun 12 '12 at 20:44
  • I could do that, but I'd rather get the readability and association by doing it the way I'm asking about. – Achilles Jun 12 '12 at 20:48
  • I suggest an extension on string so you could use it like `T target = xmlString.ParseXml();` This way it is still readable, but you don't have to break every C# developers brain. – cadrell0 Jun 12 '12 at 20:50
  • 1
    Where does `_Serializer` come from? It appears to be a a static member on your Extension class that needs to be set before you can use they extension methods. I know this isn't http://codereview.stackexchange.com/, but that is kind of scary and I would question whether or not this even belongs in an extension method. – cadrell0 Jun 12 '12 at 20:55
  • It is an instance of the .NET XML serializer and deserialzer. – Achilles Jun 13 '12 at 18:56

2 Answers2

5

How can I name the projects to convey their meaning while at the same time differentiating that they are implemented in different languages?

I would actually to not convey this. Give both projects names which are meaningful in and of themselves. Each project should be usable by both languages, so the names should make sense regardless of the language used to create the project.

Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
  • 1
    +1 - Good naming conventions are essential to programmers. It makes all the difference in discovery, which is probably half of what we do. – JDB Jun 12 '12 at 20:07
2

Ah... just saw your comment. I would recommend implementing most of your extension methods in C# and calling it "Core", then implement the extra features in VB.NET and call it "Extended".

Then, have the VB.NET explicitly reference Core and inherit from it. Users can then use the Core assembly for most of the tasks, or Extended for the additional features.

EDIT: I still think your users would be better off if you figured out a way NOT to split the assemblies, but obviously I don't know all of your requirements/implementation details.

JDB
  • 25,172
  • 5
  • 72
  • 123