Is it possible using mono Cecil to get and set IL comments? I'm trying to add a comment to an assembly using a patcher, so that if the patcher gets run on the file twice it can access the comment and avoid making changes twice.
No you can not add comments to the methodbody.
But you can persist your information in the metadata by adding them as custom attributes on the first run. When you need complex data it could be a bit tricky since types in custom attributes are limited to:
One of the following types: bool, byte, char, double, float, int, long, short, string.
The type object.
The type System.Type.
An enum type, provided it has public accessibility and the types in which it is nested (if any) also have public accessibility (Section
17.2).
Single-dimensional arrays of the above types.
But when you are a bit creative it should be doable, for example when its enough to mark offsets in the methodbody after a change you could add metadata like this:
public class C
{
[TypeOneChanges(new uint[] { 0, 16, 124 })]
[TypeTwoChanges(new uint[] { 5, 10 })]
public void M() { }
}
[AttributeUsage(System.AttributeTargets.Method)]
class RemarkableOffsetAttribute : Attribute
{
public uint[] Offsets { get; }
public RemarkableOffsetAttribute(uint[] offsets)
{
Offsets = offsets;
}
}
class TypeOneChangesAttribute : RemarkableOffsetAttribute
{
public TypeOneChangesAttribute(uint[] offsets) : base(offsets) { }
}
class TypeTwoChangesAttribute : RemarkableOffsetAttribute
{
public TypeTwoChangesAttribute(uint[] offsets) : base(offsets) { }
}
Related
In my project, I have this special function that does needs to evaluate the following:
State -- represented by an enum -- and there are about 6 different states
Left Argument
Right Argument
Left and Right arguments are represented by strings, but their values can be the following:
"_" (a wildcard)
"1" (an integer string)
"abc" (a normal string)
So as you can see, to cover all every single possibility, there's about 2 * 3 * 6 = 36 different logics to evaluate and of course, using if-else in one giant function will not be feasible at all. I have encapsulated the above 3 input into an object that I'll pass to my function.
How would one try to use OOP to solve this. Would it make sense to have 6 different subclasses of the main State class with an evaluate() method, and then in their respective methods, I have if else statements to check:
if left & right arg are wildcards, do something
if left is number, right is string, do something else
Repeat for all the valid combinations in each State subclass
This feels like the right direction, but it also feels like theres alot of duplicate logic (for example check if both args are wildcards, or both strings etc.) for all 6 subclasses. Then my thought is to abstract it abit more and make another subclass:
For each state subclass, I have stateWithTwoWildCards, statewithTwoString etc.
But I feel like this is going way overboard and over-engineering and being "too" specific (I get that this technically adheres tightly to SOLID, especially SRP and OCP concepts). Any thoughts on this?
Possibly something like template method pattern can be useful in this case. I.e. you will encapsulate all the checking logic in the base State.evaluate method and create several methods which subclasses will override. Something along this lines:
class StateBase
def evaluate():
if(bothWildcards)
evalBothWildcards()
else if(bothStrings)
evalBothStrings()
else if ...
def evalBothWildcards():
...
def evalBothStrings():
...
Where evalBothWildcards, evalBothStrings, etc. will be overloaded in inheritors.
there's about 2 * 3 * 6 = 36 different logics to evaluate
We can apply divide and conquer technique.
you have 6 states. It is possible to use Chain of Responibility pattern here to choose appropriate state handler
when desired state handler is found, then we can apply desired function. The appropriate function can be considered as strategy. So it is a place where Strategy pattern can be applied.
we can separate strategies by appropriate states and put them in simple factory to get desired strategy by key.
This is what we will do. So let's see it more thoroughly.
Chain of responsibility pattern
If you have a lot if else statements, it is possible to use Chain of Responsibility pattern. As wiki says about Chain of Responsibility:
The chain-of-responsibility pattern is a behavioral design pattern
consisting of a source of command objects and a series of processing
objects. Each processing object contains logic that defines the
types of command objects that it can handle; the rest are passed to
the next processing object in the chain. A mechanism also exists for
adding new processing objects to the end of this chain
So let's dive in code. Let me show an example via C#.
So this is our Argument class which has Left and Right operands:
public class Arguments
{
public string Left { get; private set; }
public string Right { get; private set; }
public MyState MyState { get; private set; }
public MyKey MyKey => new MyKey(MyState, Left);
public Arguments(string left, string right, MyState myState)
{
Left = left;
Right = right;
MyState = myState;
}
}
And this is your 6 states:
public enum MyState
{
One, Two, Three, Four, Five, Six
}
This is start of Decorator pattern. This is an abstraction of StateHandler which defines behaviour to to set next handler:
public abstract class StateHandler
{
public abstract MyState State { get; }
private StateHandler _nextStateHandler;
public void SetSuccessor(StateHandler nextStateHandler)
{
_nextStateHandler = nextStateHandler;
}
public virtual IDifferentLogicStrategy Execute(Arguments arguments)
{
if (_nextStateHandler != null)
return _nextStateHandler.Execute(arguments);
return null;
}
}
and its concrete implementations of StateHandler:
public class OneStateHandler : StateHandler
{
public override MyState State => MyState.One;
public override IDifferentLogicStrategy Execute(Arguments arguments)
{
if (arguments.MyState == State)
return new StrategyStateFactory().GetInstanceByMyKey(arguments.MyKey);
return base.Execute(arguments);
}
}
public class TwoStateHandler : StateHandler
{
public override MyState State => MyState.Two;
public override IDifferentLogicStrategy Execute(Arguments arguments)
{
if (arguments.MyState == State)
return new StrategyStateFactory().GetInstanceByMyKey(arguments.MyKey);
return base.Execute(arguments);
}
}
and the third state handler looks like this:
public class ThreeStateHandler : StateHandler
{
public override MyState State => MyState.Three;
public override IDifferentLogicStrategy Execute(Arguments arguments)
{
if (arguments.MyState == State)
return new StrategyStateFactory().GetInstanceByMyKey(arguments.MyKey);
return base.Execute(arguments);
}
}
Strategy pattern
Let's pay attention to the following row of code:
return new StrategyStateFactory().GetInstanceByMyKey(arguments.MyKey);
The above code is an example of using Strategy pattern. We have different ways or strategies to handle
your cases. Let me show a code of strategies of evaluation of your expressions.
This is an abstraction of strategy:
public interface IDifferentLogicStrategy
{
string Evaluate(Arguments arguments);
}
And its concrete implementations:
public class StrategyWildCardStateOne : IDifferentLogicStrategy
{
public string Evaluate(Arguments arguments)
{
// your logic here to evaluate "_" (a wildcard)
return "StrategyWildCardStateOne";
}
}
public class StrategyIntegerStringStateOne : IDifferentLogicStrategy
{
public string Evaluate(Arguments arguments)
{
// your logic here to evaluate "1" (an integer string)
return "StrategyIntegerStringStateOne";
}
}
And the third strategy:
public class StrategyNormalStringStateOne : IDifferentLogicStrategy
{
public string Evaluate(Arguments arguments)
{
// your logic here to evaluate "abc" (a normal string)
return "StrategyNormalStringStateOne";
}
}
Simple factory
There is no pattern like simple factory. However, it is a place where we can get instances of strategies by key. So by doing this we avoided to use multiple if else statements to choose correct strategy.
So, we need a place where we can store strategies by state and argument value. At first, let's create MyKey struct. It will have help us to differentiate State and arguments:
public struct MyKey
{
public readonly MyState MyState { get; }
public readonly string ArgumentValue { get; } // your three cases: "_",
// an integer string, a normal string
public MyKey(MyState myState, string argumentValue)
{
MyState = myState;
ArgumentValue = argumentValue;
}
public override bool Equals([NotNullWhen(true)] object? obj)
{
return obj is MyKey mys
&& mys.MyState == MyState
&& mys.ArgumentValue == ArgumentValue;
}
public override int GetHashCode()
{
unchecked // Overflow is fine, just wrap
{
int hash = 17;
hash = hash * 23 + MyState.GetHashCode();
hash = hash * 23 + ArgumentValue.GetHashCode();
return hash;
}
}
}
and then we can create a simple factory:
public class StrategyStateFactory
{
private Dictionary<MyKey, IDifferentLogicStrategy>
_differentLogicStrategyByStateAndValue =
new Dictionary<MyKey, IDifferentLogicStrategy>()
{
{ new MyKey(MyState.One, "_"), new StrategyWildCardStateOne() },
{ new MyKey(MyState.One, "intString"),
new StrategyIntegerStringStateOne() },
{ new MyKey(MyState.One, "normalString"),
new StrategyNormalStringStateOne() }
};
public IDifferentLogicStrategy GetInstanceByMyKey(MyKey myKey)
{
return _differentLogicStrategyByStateAndValue[myKey];
}
}
So we've written our strategies and we've stored these strategies in simple factory StrategyStateFactory.
Then we need to check the above implementation:
StateHandler chain = new OneStateHandler();
StateHandler secondStateHandler = new TwoStateHandler();
StateHandler thirdStateHandler = new ThreeStateHandler();
chain.SetSuccessor(secondStateHandler);
secondStateHandler.SetSuccessor(thirdStateHandler);
Arguments arguments = new Arguments("_", "_", MyState.One);
IDifferentLogicStrategy differentLogicStrategy = chain.Execute(arguments);
string evaluatedResult =
differentLogicStrategy.Evaluate(arguments); // output: "StrategyWildCardStateOne"
I believe I gave basic idea how it can be done.
Are there any indicators to deciding whether to use a parameter or member variable?
See below example:
open class BankAccount(val accountCode: String, val accountName: String,
var balance : Double = 0.0) {}
vs.
open class BankAccount(val accountCode: String, val accountName: String) {}
var balance : Double = 0.0
The only question you have to ask is "Is this something that should be set via the constructor?" If yes, then use a parameter. If not, use a property. By adding var you're still making the declaration a property, you're just also adding a shortcut to initialize it from the constructor.
If you're coming from a Java background, looking at the Java equivalent would be helpful. It would be something like this:
public class BankAccount {
private final String mAccountCode;
private final String mAccountName;
private double mBalance;
public BankAccount(String accountCode, String accountName, double balance) {
mAccountCode = accountCode;
mAccountName = accountName;
mBalance = balance;
}
public BankAccount(String accountCode, String accountName) {
this(accountCode, accountName, 0.0d)
}
public void setBalance(double balance) {
mBalance = balance;
}
public double getBalance() {
return mBalance;
}
}
vs.
public class BankAccount {
private final String mAccountCode;
private final String mAccountName;
private double mBalance = 0.0d;
public BankAccount(String accountCode, String accountName) {
mAccountCode = accountCode;
mAccountName = accountName;
}
public void setBalance(double balance) {
mBalance = balance;
}
public double getBalance() {
return mBalance;
}
}
Notice that you get a constructor argument for the balance field in the first case. In either case you can update the value with a method call to the setter.
For your second question, when you should and shouldn't use val or var, the answer is "Use var to make the parameter a writable property, use val to make it a read-only property, and use nothing if you just want constructor args.
Again, the Java equivalent of something like this:
open class Example(var writable : Int, val readable : Int, constructorArg : Int) {
// Could use constructor arg to init another property
private val someOtherProperty : Int = constructorArg
// Or in the init block (the Kotlin "constructor" body)
init {
// Or do something with constructArg in the constructor
}
}
Would be something like this:
public class Example {
private int mWritable;
private final int mReadable;
private final int mSomeOtherProperty;
public Example(int writable, int readable, int contructorArg) {
mWritable = writeable;
mReadable = readable;
// Could use constructor arg to init another property
mSometOtherProperty = constructorArg;
// Or do something with constructArg in the constructor
}
public int getWritable() {
return mWritable;
}
public void setWritable(int writable) {
mWritable = writable;
}
public int getReadable() {
return mReadable;
}
The var attribute makes a property that has both a setter and a getter so you can update it.
The val attribute makes a property that only has a getter so you can read it.
The arg with no keyword makes no property - instead it is passed to the constructor for you to use as needed. This is a trivialized example so it does nothing, but in reality you would use it to either initialize other properties or with an init block.
Again, assuming you're coming from a Java background, you can use Intellij to run view the Kotlin byte code, then convert that to Java to see what the differences in the language do.
Here's the first google hit that explains this:
https://medium.com/#mydogtom/tip-how-to-show-java-equivalent-for-kotlin-code-f7c81d76fa8
Hope that helps!
TLDR: Use a parameter if you need to parameterise.
In the first case, you will be able to start an account with a non-zero balance.
If that is a scenario you find useful, it makes sense to make the balance an (optional) parameter. Otherwise, a member variable is more appropriate.
I am trying to follow the builder design pattern using modules in Reason.
I have the following type:
type userBuilderType = {
mutable name: string,
};
As well as signature type:
module type UserBuilderType = {
let name: string;
};
I am passing the UserBuilderType signature type as a functor to the BuilderPattern:
module BuilderPattern = fun(Builder: UserBuilderType) => {
let builder = {
name: "",
};
let setName = builder.name = Builder.name;
let getName () => builder.name;
};
I am then passing the appropriate value as a module doing the following:
module SetOfMixedPairs = BuilderPattern({
let name = "asd";
});
However, in order for this builder design pattern, to truly be a builder design pattern, the signature type will need to be optional. I am struggling as how to do so. If I were for instance, to edit the signature type to be empty:
module type UserBuilderType = {};
The compiler will complain: Unbound value Builder.name. Any suggestions as to how to make the signature type optional, are more than welcome. My thanks as always.
Full code can be seen here.
First of all, usually you can't implement a design pattern using some mechanism of a language, as design patterns are not expressible directly in the language type system and syntax. Design patterns describe a particular methodology for solving recurring problems in software development. As soon, as a language provides a mechanism to express a design pattern directly, this is no longer considered a design pattern. Thus something that is a design pattern in one language, becomes a mechanism in another language. For example, a loop in assembly language is a design pattern, though in most modern languages it's a syntactic construct. A presence of design patterns usually indicates a lack of expressivity of a particular language or programming paradigm. Though, no matter how expressive your language, there always be abstractions, that can't be implemented directly using the language mechanisms.
You should also understand that GoF design patterns were written with the OOP paradigm in mind with peculiarities and limitations of OOP languages of that time. So they are not always applicable or even needed in OCaml/Reason or any other languages with parametric polymorphism and first-class functions.
In particular, the problem that the Builder pattern is trying to solve is an absence of first-class constructors and parametric polymorphism. Since we have both in Reason, we are usually not bothered with designing complex hierarchies of types. Another limitation of OOP is an absence of algebraic data types, that are ideal language mechanism for implementing complex compound data structures such as abstract syntax trees (expression parsing trees) and so on.
With all this said, you can still use the Builder pattern in Reason, but most likely you don't actually need it, as the language provides much better and more expressible mechanisms for solving your problem. Let's use the SportsCarBuilder code from Wikipedia, as our working example,
/// <summary>
/// Represents a product created by the builder
/// </summary>
public class Car
{
public string Make { get; }
public string Model { get; }
public int NumDoors { get; }
public string Colour { get; }
public Car(string make, string model, string colour, int numDoors)
{
Make = make;
Model = model;
Colour = colour;
NumDoors = numDoors;
}
}
/// <summary>
/// The builder abstraction
/// </summary>
public interface ICarBuilder
{
string Colour { get; set; }
int NumDoors { get; set; }
Car GetResult();
}
/// <summary>
/// Concrete builder implementation
/// </summary>
public class FerrariBuilder : ICarBuilder
{
public string Colour { get; set; }
public int NumDoors { get; set; }
public Car GetResult()
{
return NumDoors == 2 ? new Car("Ferrari", "488 Spider", Colour, NumDoors) : null;
}
}
/// <summary>
/// The director
/// </summary>
public class SportsCarBuildDirector
{
private ICarBuilder _builder;
public SportsCarBuildDirector(ICarBuilder builder)
{
_builder = builder;
}
public void Construct()
{
_builder.Colour = "Red";
_builder.NumDoors = 2;
}
}
public class Client
{
public void DoSomethingWithCars()
{
var builder = new FerrariBuilder();
var director = new SportsCarBuildDirector(builder);
director.Construct();
Car myRaceCar = builder.GetResult();
}
}
We will provide a one-to-one translation from C# to Reason, to show the direct counterparts of C# mechanisms in Reason. Note, we will not build an idiomatic Reason code, people will unlikely follow the Builder Pattern in Reason.
The Car class defines an interface of a build product. We will represent it as a module type in Reason:
module type Car = {
type t;
let make : string;
let model : string;
let numDoors : int;
let colour: string;
let create : (~make:string, ~model:string, ~numDoors:int, ~colour:string) => t;
};
We decided to make the car type abstract (letting an implementor to choose a particular implementation, whether it would be a record, an object, or maybe an key to a SQL database of cars.
We will now define a corresponding interface for the car builder:
module type CarBuilder = {
type t;
type car;
let setColour : (t,string) => unit;
let getColour : t => string;
let setNumDoors : (t,int) => unit;
let getNumDoors : t => int;
let getResult : t => car;
}
Now let's implement a concrete builder. Since we decided to make the car type abstract, we need to parametrize our concrete builder with the car type. In OCaml/Reason, when you need something to parametrize with a type, you usually use functors.
module FerariBuilder = (Car: Car) => {
type t = {
mutable numDoors: int,
mutable colour: string
};
exception BadFerrari;
let setColour = (builder, colour) => builder.colour = colour;
let getColour = (builder) => builder.colour;
let setNumDoors = (builder, n) => builder.numDoors = n;
let getNumDoors = (builder) => builder.numDoors;
let getResult = (builder) =>
if (builder.numDoors == 2) {
Car.create(~make="Ferrari", ~model="488 Spider",
~numDoors=2, ~colour=builder.colour)
} else {
raise(BadFerrari)
};
};
And finally, let's implement a director.
module Director = (Car: Car, Builder: CarBuilder with type car = Car.t) => {
let construct = (builder) => {
Builder.setColour(builder, "red");
Builder.setNumDoors(builder, 2)
};
};
I will let you implementing the user code as an exercise. Hint, you need to start with a concrete implementation of the Car interface. You may look and play with the code (including the OCaml and Javascript version) at Try Reason.
Hi when you have a method with same signature let's say.
void getErrorMessage(int errorCode){
}
void getErrorMessage(int domain){
}
I know I have to change the name or differentiate the parameter but what would be the best way to approach?
---------------------------Edited.
How about for constructor?
For example
public ErrorMessage(int errorCode){
}
public ErrorMessage(int domain){
}
You could make the method name explicit:
getErrorByErrorCode(int errorCode)
And
getErrorByDomain(int domain)
You can add a "ByFoo" to the end of the method, like: getErrorMessageByCode or getErrorMessageByDomain
The least dangerous and easiest-to-understand way to do this is:
public class ErrorCode {
private int intCode;
ErrorCode(int intCode) {
this.intCode = intCode;
}
int getIntegerCode() {
return intCode;
}
}
public class Domain {
private int domain;
Domain(int domain) {
this.domain = domain;
}
int getIntegerCode() {
return domain;
}
}
Message getErrorMessage(ErrorCode errorCode)
Message getErrorMessage(Domain domain)
Note the classes are immutable. You should probably also override equals. Use these classes everywhere you would have used the integer values.
Now it is impossible to mistake an error code for a domain anywhere in your code. If you mistake one for the other you will get a compiler error, and the compiler will choose the correct implementation of getErrorMessage. You extract the integer value from the object only when you need to perform integer operations on it.
So i have a class that makes an array list for me and i need to access it in another class through a constructor but i don't know what to put into the constructor because all my methods in that class are just for manipulating that list. im either getting a null pointer exception or a out of bounds exception. ive tried just leaving the constructor empty but that dosent seem to help. thanks in advance. i would show you code but my professor is very strict on academic dishonesty so i cant sorry if that makes it hard.
You are confusing the main question, with a potential solution.
Main Question:
I have a class ArrayListOwnerClass with an enclosed arraylist property or field.
How should another class ArrayListFriendClass access that property.
Potential Solution:
Should I pass the arraylist from ArrayListOwnerClass to ArrayListFriendClass,
in the ArrayListFriendClass constructor ?
It depends on what the second class does with the arraylist.
Instead of passing the list thru the constructor, you may add functions to read or change, as public, the elements of the hidden internal arraylist.
Note: You did not specify a programming language. I'll use C#, altought Java, C++, or similar O.O.P. could be used, instead.
public class ArrayListOwnerClass
{
protected int F_Length;
protected ArrayList F_List;
public ArrayListOwnerClass(int ALength)
{
this.F_Length = ALength;
this.F_List = new ArrayList(ALength);
// ...
} // ArrayListOwnerClass(...)
public int Length()
{
return this.F_Length;
} // int Length(...)
public object getAt(int AIndex)
{
return this.F_List[AIndex];
} // object getAt(...)
public void setAt(int AIndex, object AValue)
{
this.F_List[AIndex] = AValue;
} // void setAt(...)
public void DoOtherStuff()
{
// ...
} // void DoOtherStuff(...)
// ...
} // class ArrayListOwnerClass
public class ArrayListFriendClass
{
public void UseArrayList(ArrayListOwnerClass AListOwner)
{
bool CanContinue =
(AListOwner != null) && (AListOwner.Length() > 0);
if (CanContinue)
{
int AItem = AListOwner.getAt(5);
DoSomethingWith(Item);
} // if (CanContinue)
} // void UseArrayList(...)
public void AlsoDoesOtherStuff()
{
// ...
} // void AlsoDoesOtherStuff(...)
// ...
} // class ArrayListFriendClass
Note, that I could use an indexed property.