We Keep Coding

Is a struct with the format 1.0.0 possible?

So I'm playing around a bit with the possibilities of modules for an application I'm building and I'd like to version them.
These modules which are dlls implement an interface with a property for the version of this module. The format should be "Major.Minor.Build".
If I create a property of type String, the possibility of a version like "Major.Minor" or "Major.Minor.Build.Revision" exists. I want to prevent that.
So I had the idea of a struct like Double but with a third digit. My question is now, is this even possible and if yes, how can I implement something like this?
In the class it should look like this:
public class MyModuleContext : IModuleContext
{
public ModuleVersion Version { get; set; } = 1.0.0;
// more interface things ...
}
Thanks for your help :)

Just create a class that meets your needs:
public class Version: IVersion
{
public int Major { get; }
public int Minor { get; }
public int Build { get; }
public override string ToString =>
$”{Major}.{Minor}.{Build}”
public Version(int major, int minor, int build)
{
//omitted argument validation
Major = major;
Minor = minor;
Build = build;
}
}
If you are mainly going to be passing IVersion references around, you are better off implementing this as a reference type or you’ll be boxing the value type all over the place.
It’s up to you if you want to implement value equality semantics, comparison logic, etc. It’s all pretty trivial.

Type constraints in Attributes

I want to write my enum with custom attributes, for example:
public enum SomeEnum: long
{
[SomeAttribute<MyClass1>]
Sms = 1,
[SomeAttribute<MyClass2>]
Email = 2
}
but attributes doesn't support generics. Well, the most similar solution is:
public enum SomeEnum: long
{
[SomeAttribute(typeof(MyClass1))]
Sms = 1,
[SomeAttribute(typeof(MyClass2))]
Email = 2
}
And here is problem: I want Class1 to be inherited from ICustomInterface, so with generics I can write constraint:
[AttributeUsage(AttributeTargets.All)]
class SomeAttribute<T> : Attribute where T: ICustomInterface
{
}
but attributes doesn't support generics.
so finally question is: how can I check in compile time (like T constraints) that type is implementing some interface?

Very simple to your final question:
so finally question is: how can I check in compile time (like T
constraints) that type is implementing some interface?
You can not do that.
But you can check it at runtime, with some reflection methods like:
Type.IsAssignableFrom

While i've had similar problems you won't get compile time checking for this.
For now this:
public class SomeAttribute : Attribute
{
public SomeAttribute(Type given)
{
Given = given;
Required = typeof (INotifyDataErrorInfo);
}
public Type Given { get; set; }
public Type Required { get; set; }
public bool Valid()
{
return Required.IsAssignableFrom(Given);
}
}
public enum TestEnum
{
[Some(typeof(string))]
Sms = 1,
[Some(typeof(string))]
Email = 2
}
Is far as you're gonna get sadly.
Though as far as i can recall, if you use PostSharp there is a way to invoke code dependant compile time checks if that's what you're after. That may not point out flaws visually in your IDE, but it still ensures that other devs have to ensure that a certain type is passed.

Forcing named arguments in C#

C# 4 introduced a feature called named arguments which is especially useful in scenarios like
int RegisterUser(string nameFirst, string nameLast, string nameMiddle, string email)
Is there a way to force using named arguments? Maybe some attribute to apply to a method or a compiler switch I'm not aware of? I guess it can be done with code inspector tools but just want to know if there is other way.
p.s.
For those interested why one may need it and why not just use a class/struct to utilize object initializers there are scenarios when it's impossible. Like calls to libraries not in your control or weird code conventions you have to obey.

It's possible to force the callers to always use named args. I wouldn't do this in most circumstances because it's rather ugly, but it depends on how badly safe method usage is needed.
Here is the solution:
int RegisterUser(
#if DEBUG
int _ = 0,
#endif
string nameFirst = null,
string nameLast = null,
string nameMiddle = null,
string email = null) { /*...*/ }
The first parameter is a dummy that shouldn't be used (and is compiled away in Release for efficiency). However, it ensures that all following parameters have to be named.
Valid usage is any combination of the named parameters:
RegisterUser();
RegisterUser(nameFirst: "Joe");
RegisterUser(nameFirst: "Joe", nameLast: "Smith");
RegisterUser(email: "joe.smith#example.com");
When attempting to use positional parameters, the code won't compile.

No, not in the C# language. It will always accept positional parameters if all the parameters are supplied.
You could build a custom FxCop rule or an StyleCop rule to enforce this - as pointed out in the comments, it is likely a StyleCop rule you would be interested in (thanks to Kris).

Sorry for a shameless plug!
I implemented a Roslyn analyzer to enforce using named arguments for a method.
So if you install the RequireNamedArgs analyzer and add a special comment before a method that should be invoked with named arguments:
//[RequireNamedArgs]
int RegisterUser(string nameFirst, string nameLast, string nameMiddle, string email)
The analyzer will emit an error if a caller attempts to use positional arguments instead of named.
Take a look at it in action:
If you decide to give it a go -- do so at your own risk :)

I've also sought a way to force named arguments. Optional parameters can be dangerous, especially if you have multiple parameters of the same type. Overloads are almost always a safer solution, but there are times when you have a method that can take many combination of arguments, so creating 20 overloads to account for ever possibility is overkill.
In extreme situations where it is of the utmost importance that arguments be named at all times, I will create an argument class with no defined constructor. In your case, you could do this:
public class UserRegistrationArguments
{
public string nameFirst { get; set; }
public string nameLast { get; set; }
public string nameMiddle { get; set; }
public string email { get; set; }
}
Call it like this:
RegisterUser(new UserRegistrationArguments { nameFirst = "Bob", nameLast = "Slob" });
You could also simplify it like this:
public class UserRegistrationArguments
{
public string nameMiddle { get; set; }
public string email { get; set; }
}
int RegisterUser(string nameFirst, string nameLast, UserRegistrationArguments args = null)
...and do this:
RegisterUser("Bob", "Slob", new UserRegistrationArguments { nameMiddle = "Teh" });
This way, you only have one optional parameter and that's for your optional parameters.
Edit: Maybe I didn't read the OP correctly. You're not using optional arguments? If not then this answer probably doesn't help you.

I'm using another method. In my setup I have 1 parameter which I always expect, then come a bunch of optional strings which I really want to be sure the user chose actively. So my first string in this list is a "trap" value, which if set, throws an error. Like this:
public HtmlString Toolbar(DynamicEntity target = null, string dontRelyOnParameterOrder = Constants.RandomProtectionParameter, string actions = null, string contentType = null, object prefill = null)
{
if (!Enabled) return null;
protectAgainstMissingParameterNames(dontRelyOnParameterOrder);
var toolbar = new ItemToolbar(target, actions, contentType, prefill);
return new HtmlString(toolbar.Toolbar);
}
private void protectAgainstMissingParameterNames(string criticalParameter)
{
if(criticalParameter != Constants.RandomProtectionParameter)
throw new Exception("when using the toolbar command, please use named parameters - otherwise you are relying on the parameter order staying the same.");
}
Hope you like it :)

Are there any anti-pattern names for writing code like this?

Here is some code that uses a parameter class to contain the possible parameters to the Show() method. The values in this FooOption class aren't very related. You can see this by looking at the implementation of Show() below. I know this is bad code, but are there any anti-patterns related to doing this?
class FooOptions {
public int? Id { get; set; }
public string BazContext { get; set; }
public int? BazId { get; set; }
}
class BarMgr {
public Bar Show(FooOptions options) {
if (options == null)
options = new FooOptions();
if (options.Id.HasValue)
return svc.GetBar(options.Id.Value);
if (!string.IsNullOrEmpty(options.BazContext) && options.BazId.HasValue)
return svc.GetBar(options.BazContext, options.BazId.Value);
return null;
}
}
Update:
I know that parameter objects are not an anti-pattern. In my experience, parameter object properties are related. This is the possible anti-pattern that I am trying to locate. setting all three properties makes no sense.

After your update, here my answer:
As far as I know, there is no real name for an anti-pattern like this, but there is at least one principle that this method violates:
The Single-Responsibility-Principle.
And it really is a problem of the method and not of the parameter object.

It's called the parameter object pattern, and it's not considered an antipattern -- it's a good way to deal with methods that would otherwise have too many parameters.

There might be an anti-pattern if you use options a lot we have something called feature envy and is an indication that you might want to move functionality into the actual feature being used.

C# Attributes - Arrays or Duplicates?

I am creating a network chat client in C# as a side project. In addition to simple text messages, I also have slash-prefixed commands that can be entered into the input TextBox. I used a modular approach by creating an enum that contains all the various commands, and then decorating those commands with attributes.
The attributes specify what slash-prefixed command can be entered to trigger the command, as well as any aliases to the primary command identifier and the command's usage.
Example:
public enum CommandType : byte
{
[PrimaryIdentifier("file"),
AdditionalIdentifier("f"),
CommandUsage("[<recipient>] [<filelocation>]")]
FileTransferInitiation,
[PrimaryIdentifier("accept"),
AdditionalIdentifier("a")]
AcceptFileTransfer,
// ...
}
My problem arises when I try to allow multiple aliases to the primary command. I have attempted this two ways: by allowing duplicates of the AdditionalIdentifier attribute, or by making the constructor argument in AdditionalIdentifier a params string[].
With the former, I implemented it by decorating the attribute class with AttributeUsage and setting AllowMultiple to true. While this does indeed achieve what I'm looking for, I'm feeling like it could get really noisy really fast to have several lines of aliases, in addition to the other attributes.
The latter also works, however, it generates the compiler warning CS3016, and says that that approach is not CLS-compliant. Obviously, this doesn't necessarily stop me from still using it, but I've learned to always treat warnings as errors.
My actual question is should I ignore my objections with duplicates and just go ahead and use them, or is there some other solution that could be used?
Thank you.

You could also use "params string[] aliases" in the constructor to allow a variable argument list:
[AttributeUsage(AttributeTargets.Method)]
class TestAttribute : Attribute
{
public TestAttribute(params string[] aliases)
{
allowedAliases = aliases;
}
public string[] allowedAliases { get; set; }
}
This would allow you to do:
[Test("test1", "test2", "test3")]
static void Main(string[] args)

Personally I would go with the AllowMultiple approach: I don't think the "noise" is going to be that much of a problem unless you really have truckloads of identifiers for each command. But if you don't like that and want to stay CLS-compliant, one other solution would be to provide overloaded constructors for AdditionalIdentifierAttribute:
public AdditionalIdentifierAttribute(string id) { ... }
public AdditionalIdentifierAttribute(string id1, string id2) { ... }
public AdditionalIdentifierAttribute(string id1, string id2, string id3) { ... }
The downside is that this does limit you to a predetermined number of identifiers.
That said, CLS compliance is really only a major consideration if you are building a library that others are likely to use (and specifically from other languages). If this type or the library is internal to your application, then it's reasonable to ignore CLS compliance warnings.
EDIT: Thinking further about this, you have quite a lot of attributes on those enums. You might want to consider creating an abstract Command class instead, and exposing the identifiers, usage, etc. as properties of that class; then derive concrete types of Command which return the appropriate values from those properties. This potentially also allows you to move the handling logic into those Command objects rather than switching on the enum value.

Why not have a single attribute with multiple properties? Have the property for the alias take a comma-separated list. This is the approach they take in MVC for things like the AuthorizeAttribute for Roles. Internally, the property parses the string into an array for ease of use in the attribute class, but it allows you an easy way to set up your configuration.
public class IdentifierAttribute
{
public string Name { get; set; }
public string Usage { get; set; }
private string[] aliasArray;
private string aliases;
public string Aliases
{
get { return this.aliases; }
set
{
this.aliases = value;
this.aliasArray = value.Split(',').Trim();
}
}
}
Then use it like:
public enum CommandType : byte
{
[Identifer( Name = "file", Aliases = "f", Usage = "..." )]
FileTransferType,
...
}

Yet another approach would be to have the attribute take an array of strings as a constructor parameter - that way, you get the compiler to parse the array for you (at the expense of a little more goop when applying the attribute) thus:
[Identifiers(new string[] {"Bill", "Ben", "Ted"})]
A quick 'n dirty example of implementing & using such a technique looks like this:
using System;
using System.Collections.ObjectModel;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
SomeClass.TellMeAboutYourself();
}
}
public class Identifiers : Attribute
{
private string[] names;
public Identifiers(string[] someNames)
{
names = someNames;
}
public ReadOnlyCollection<string> Names { get { return new ReadOnlyCollection<string>(names); } }
}
[Identifiers(new string[] {"Bill", "Ben", "Ted"})]
static class SomeClass
{
public static void TellMeAboutYourself()
{
Identifiers theAttribute = (Identifiers)Attribute.GetCustomAttribute(typeof(SomeClass), typeof(Identifiers));
foreach (var s in theAttribute.Names)
{
Console.WriteLine(s);
}
}
}
}