I am trying to bind a .AAR library getting the following error
CS0738 'SecureString' does not implement interface member 'ICharSequence.SubSequenceFormatted(int, int)'. 'SecureString.SubSequenceFormatted(int, int)' cannot implement 'ICharSequence.SubSequenceFormatted(int, int)' because it does not have the matching return type of 'ICharSequence'
This is a problem that occurs with binding Java methods with covariant return types.
There are two ways to fix this issue:
(1).Add a partial class declaration for SecureString and explicitly implement SecureString.SubSequenceFormatted(int, int).
(2).Remove the covariance from the generated C# code.
For more information, you can refer to this document https://learn.microsoft.com/en-us/xamarin/android/platform/binding-java-library/troubleshooting-bindings
I can't see any mention of it in the API Blueprint spec, although there was a feature request to add an include directive for including other files.
Include is not to be confused with the non-standard directive of the same name for including other files (although the aglio tool for API Blueprint does support the latter).
Include is defined in the MSON specification, which is referred to by the API Blueprint spec. For example, in the Data Structures section of an API Blueprint file, the named types defined therein are defined using MSON.
Include is like extends in Java - it makes the type that is currently being defined inherit all the fields of the specified "supertype". The keyword Include may be followed by the name of a named type (its usual usage) or, somewhat strangely, by an inline type definition:
MSON defines a Mixin Type that supports multiple inheritance from
another Named Type. The Named Type being inherited MUST be a Structure
Type or its sub-type.
Nested Member Types defined in and inherited from the mixed-in Named
Type are added at the same indentation level of the Mixin Type.
Mixin Type → - Include Type Name | - Include Type Definition
I have the following, in CommandEnum.ts:
export enum CommandEnum {
createProject,
renameProject,
hablaBabla
}
in a module which I am able to reference from implementation code, using
import {CommandEnum} from '../server/contracts/CommandEnum'
let x = CommmandEnum.hablaBabla
The enum file is compiled into a javascript function with export logic, in CommandEnum.js.
This now works fine, but I want to reference this enum in my interfaces as well, I try:
/// <reference path="../contracts/CommandEnum.ts" />
namespace ValueTypes {
export interface Command {
type : CommandEnum;
referenceId : string;
}
}
Now, this reference does not import the CommandEnum type, but some of the other combinations of modules / namespace / export default I have tried does. I can get the reference syntax to work, but not the module syntax and the other way around - but not both.
Is this actually possible? Using an enum from a pure definitions interface file seems like a very common scenario. But when the interface is implemented the enum must be available in "function form" and these two models does not seem to combine?
I had the same problem with classes, which I wanted to namespace, .Net-style - which I had to give up. Classes, however, are not referenced in my interfaces - enums are.
I work with node.js and compile to individual files, not a single concated output.
This now works fine, but I want to reference this enum in my interfaces as well
You can move stuff from a module into the global namespace use declare global
E.g. myEnumGlobalDeclare.ts
import {MyEnum as MyEnumModule} from "./myEnum";
declare global {
declare var MyEnum: typeof MyEnumModule;
}
E.g. myEnumGlobalDefine.ts
import {MyEnum as MyEnumModule} from "./myEnum";
MyEnum = MyEnumModule;
Or something similar ^. Of course this means your runtime should support global augmentation e.g. in nodejs you need to use globals and in browsers window.
More
I definitely do not recommend going down this path. Instead create a global types.ts module and just use that everywhere. E.g. alm has this file : https://github.com/alm-tools/alm/blob/master/src/common/types.ts
I'll start by saying that I'm working off the assumption that static array initializers are turned into private nested classes by the compiler, usually with names like __StaticArrayInitTypeSize=12. As I understand it, having read this extremely informative article, these private classes are value types, and they aren't tagged with the CompilerGeneratedAttribute class.
I'm working on a project that needs to process certain types and ignore others.
I have to be able to process custom struct types, which, like the generated static array initializer classes, are value types. I must ignore the generated static array initializer classes. I also must ignore enumerations and delegates.
I'm pulling these classes with Linq, like so:
var typesToProcess = allTypes.Where(type => !type.IsEnum &&
!type.IsArray &&
!type.IsSubclassOf(typeof(Delegate)));
I'm fairly sure that the IsArray property isn't what I think it is. At any rate, the generated static array initializer class still shows up in the typesToProcess Enumerable.
Has anyone else dealt with this? How can I discern the difference between a custom struct and a generated static array initializer class? I could hack it by doing a string comparison of the type name against __StaticArrayInitTypeSize, but is there a cleaner solution?
Well, having just tried it myself with the C# 4 compiler, I got an internal class called <PrivateImplementationDetails>{D1E23401-19BC-4B4E-8CC5-2C6DDEE7B97C} containing a private nested struct called __StaticArrayInitTypeSize=12.
The class contained an internal static field of the struct type called $$method0x6000001-1. The field itself was decorated with CompilerGeneratedAttribute.
The problem is that all of this is implementation-specific. It could change in future releases, or it could be different from earlier releases too.
Any member name containing <, > or = is an "unspeakable" name which will have been generated by the compiler, so you can view that as a sort of implicit CompilerGenerated, if that's any use. (There are any number of other uses for such generated types though.)
I have found that there is generally a singe type or namespace that takes in any particular enum as a parameter and as a result I have always defined those enums there. Recently though, I had a co-worker make a big deal about how that was a stupid thing to do, and you should always have an enum namespace at the root of your project where you define everyone of your enum types.
Where is the best place to locate enum types?
Why treat enums differently to other types? Keep them in the same namespace as they're likely to be used - and assuming they're going to be used by other classes, make them top-level types in their own files.
The only type of type which I do commonly clump together is delegates - I sometimes have a Delegates.cs file with a bunch of delegates in. Less so with .NET 3.5 and Func/Action, mind you.
Also, namespaces are for separation of things that belong together logically. Not all classes belong in the same namespace just because they are classes. Likewise, not all enums belong in the same namespace just because they are enums. Put them with the code they logically belong in.
I generally try to put all my different types (classes, interfaces and enums) in their own files, regardless of how small they are. It just makes it much easier to find and manage the file they're in, especially if you don't happen to be in Visual Studio and have the "go to definition" feature available. I've found that nearly every time I've put a "simple" type like that in another class, I end up either adding on to it later on, or reusing it in a way that it no longer makes sense for it to not have its own file.
As far as which namespace, it really depends on the design of whatever you're developing. In general, I try to mimic the .NET framework's convention.
I try to put everything associated with a class in the class. That includes not just enums, but also constants. I don't want to go searching elsewhere for the file or class containing the enums. In a large app with lots of classes and folders, it wouldn't always be obvious where to put the enum file so it would be easy to find.
If the enum if used in several closely-related classes, you could create a base class so that the common types like enums are shared there.
Of course, if an enum is really generic and widely used, you may want to create a separate class for them, along with other generic utilities.
I think you put Enums and Constants in the class that consumes them or that uses them to control code decisions the most and you use code completion to find them. That way you don't have to remember where they are, they are associated with the class. So for example if I have a ColoredBox class then I don't have to think about where they are at. They would be part of ColoredBox. ColoredBox.Colors.Red, ColoredBox.Colors.Blue etc. I
I think of the enum and constant as a property or description of that class.
If it used by multiple classes and no one class reigns supreme then it is appropriate to have an enum class or constants class.
This follows rules of encapsulation. Isolating properties from dissimilar classes. What if you decide to change the RGB of Red in Cirle objects but
you don't want to change the red for ColoredBox objects? Encapsulating their properties enables this.
I use nested namespaces for this. I like them better than putting the enum within a class because outside of the class you have to use the full MyClass::MyEnum usage even if MyEnum is not going to clash with anything else in scope.
By using a nested namespace you can use the "using" syntax. Also I will put enums that relate to a given subsystem in their own file so you don't get dependency problems of having to include the world to use them.
So in the enum header file you get:
// MyEnumHeader.h
// Consolidated enum header file for this dll,lib,subsystem whatever.
namespace MyApp
{
namespace MyEnums
{
enum SomeEnum { EnumVal0, EnumVal1, EnumVal2 };
};
};
And then in the class header file you get:
// MyInterfaceHeader.h
// Class interfaces for the subsystem with all the expected dependencies.
#include "MyEnumHeader.h"
namespace MyApp
{
class MyInterface
{
public:
virtual void DoSomethingWithEnumParam (MyEnums::SomeEnum enumParam) = 0;
};
};
Or use as many enum header files as makes sense. I like to keep them separate from the class headers so the enums can be params elsewhere in the system without needing the class headers. Then if you want to use them elsewhere you don't have to have the encapsulating class defs as you would if the enums were declared within the classes.
And as mentioned before, in the outer code you can use the following:
using namespace MyApp::MyEnums;
What environment?
In .NET I usually create an empty class file, rename it to MyEnum or whatever to indicate it holds my enum and just declare it in there.
If my enumeration has any chance of ever being used outside the class I intend to use it, I create a separate source file for the enum. Otherwise I will place it inside the class I intend to use it.
Usually I find that the enum is centered around a single class -- as a MyClassOptions type of thing.
In that case, I place the enum in the same file as MyClass, but inside the namespace but outside the class.
namespace mynamespace
{
public partial class MyClass
{
}
enum MyClassOptions
{
}
}
I tend to define them, where their use is evident in the evident. If I have a typedef for a struct that makes use of it for some reason...
typedef enum {
HI,
GOODBYE
} msg_type;
typdef struct {
msg_type type;
union {
int hivar;
float goodbyevar;
}
} msg;