I'm writing a Roslyn Source Generator which generates code based on the members of a specified interface.
For example, given the following interface:
interface IFoo
{
string Bar { get; set; }
}
I want to generate (within other code) the following property:
string IFoo.Bar { get; set; }
So far, I'm able to generate this:
System.String IFoo.Bar { get; set; }
which would work, but is there a way to use the string keyword, given that I don't know until runtime, when I'm analysing a particular interface type, what the type will actually be?
I've got the INamedTypeSymbol representing the System.String type. Is there a way to lookup a language keyword based on this?
I just discovered that ((INamedTypeSymbol)namedType).ToDisplayString() appears to give me what I want.
Related
I am referring to the Google.Apis.Admin.Directory.directory_v1.Data.User type.
The property type of Addresses, for example, in beta versions (i.e. 1.7 and older) was
public virtual System.Collections.Generic.IList<UserAddress> Addresses { get; set; }
In later versions (currently 1.9.1), they are all of type object.
public virtual object Addresses { get; set; }
What are the reasons behind the change and usage scenarios?
I trawled the release notes, the web, google group, SO, etc. and found no explanation on this.
A change to the backend had the unintended consequence of changing the discovery document for the service, making the addresses field (and others) being marked as type=any. This causes problems for strongly types languages like .NET, as you've found. The team is aware of the issue but it's unclear when a fix will be available.
With regards to the cpp tag. This pattern is relevant generally to parameterization, and can be implemented in C++ with templates. My primary query is whether this is a logically solveable pattern (which I believe it isn't as specified) in C++ and the AVM2, with a preference to solving it with haxe. The particular code sample and query in general, written in Haxe, compiles to the relevant C++ target in a logically identical way.
I am inquiring if there is fix to this pattern with:
Parameterization logic
There is some other way to maintain
the link of free objects other than a next property close to the
optimal implementation of a direct typed member access as
facilitated by said next property (eg avoiding a reflective/switch call for access to the next member)
I am aware there are other
pooling implementations, that is not what I am asking.
Question:
It would appear that there is no way to define a parameterized pool for a Class that extends from a Class that itself is pooled because the subclass cannot conform to Poolable_i interface because it cannot redefine the next property. Is this a valid conclusion?
Ie: the a Pool_pointer<Destination> cannot exist because Destination
cannot conform to any useful constraint specified in Pool_pointer<Destination>
For instance:
Poolable_i<T> is a base that hase a single property next:T
Point3d implements Poolable_i<Point3d>
Destination extends Point3d {
public var time:Time;
}
This is also presuming that you do not wish to use a base class that itself is parameterized, eg Point3d_base<T:{Poolable_i<T>,Point3d_base}> because one may require a hierarchy with a depth greater than 1.
Of course this can be solved in multiple ways with preprocessing as I intend to do. I am just curious if I am missing something with regards to the impossibility of said templating implementation.
package test.shared;
class Pool_pointer<T:Poolable_i<T>> implements Pool_i<T> {
public var free:T;
public function new() {
}
public function destroy():Void {
}
public inline function get():T {
var r:T=null;
if(free==null) {
r=new T();
} else {
r=free;
free=r.next;
}
return r;
}
public inline function put(v:T):Void {
v.next=free;
free=v;
}
}
The solution is to parameterize the entire hierarchy with regards to functionality declarations and create typedefs/specific Classes for concrete implementations.
Destination_base<NextT> -> Destination extends Destination_base<Destination>
^
|
Point3d_base<NextT> -> Point3d extends Point3d_base<Point3d>
Implementation hierarchy is parameterized. Ugh. Love thy preprocessing.
I am designing a laboratory system for an alloy steel company, in this system we have
some type of tests(e.g Analysis Test, Impact Test, ...) must be apply on each product in production line, I used the TestTemplate class for define each test type template(e.g Analysis test template).
Each test type, has some parameter and each parameter could be in form of:
Ranged values (min,max)
Single value (value)
Selectable value (one or more value selected from a values list)
(till now, and in future may find some new parameter types).
Also for each production we should define some nominal values for each test type template( in the other word desired values for each test type template), for example for productA the nominal values for the analysis test could be as below:
Carbon range: (Min=0.23 Max=0.65)
Fe range: (Min=1.25 Max=1.75)
Cu range: (Min=0.87 Max=1.02)
and for ProductB the nominals could be as:
Carbon range: (Min=0.43 Max=0.55)
Fe range: (Min=1.15 Max=1.65)
Cu range: (Min=0.57 Max= 1.12)
Pb range: (value = 0.12) /* single value type parameter*/
And this is my design for this problem
Main goal of my design is to achieve a dynamic structure for the test templates, is there any design pattern or some best practices for this case, or is this design good, enough?
I congratulate you with your design. This design has a very clear distinction between class and instance and is not bad at all.
Your question is unclear. What do you think is wrong with your design or needs improvement? Sometimes asking the right question is what will give you the right answer.
One thing I would have improved upon is the TestParameter class. I'd probably have generalized that. In other words, I would have made a RangeTestParameter, SingleValueTestParameter and a SelectableTestParameter. I would've made that generalized TestParameter include a factory method too:
ITestParameterValue ITestParameter.createValue()
Implemented by SelectableParameter it would return a SelectableValue. That SelectableValue would have been supplied with a set of selectable/permitted values via its constructor.
This way you could address two points in your design that triggered questions I would have asked myself if this was my design:
TestParameterType: Why design a type class when the type is available to you at compile-time? How are you going to ensure that your Code parameter contains a valid and functional value? Who is responsible for creating these types based upon these Codes?
PermitedValue: Does TestParameter have a list of ParameterValues only if the TestParameter has a (Code) reference to the ParameterType Selectable? What if it doesn't? Who ensures it does? Who knows how to interpret a TestParameter in this particular way? Only SelectableValue? Only those who have read the if statement in your class diagram?
If you'd like to present your users with a list of possible parameters you can create a TestParameterFactory that links your parameter types to some additional info. Here is a simple Java version of such a factory:
public class TestParameterFactory {
private final Map<String, ITestParameter.class> parameterTypes;
public TestParameterFactory() {
parameterTypes = new HashMap<String, ITestParameter.class>();
parameterTypes.put("Range", RangeTestParameter.class);
parameterTypes.put("Selectable", SelectableTestParameter.class);
parameterTypes.put("Single value", SingleValueTestParameter.class);
}
public getParameterTypes() {
return parameterTypes;
}
public ITestParameter createParameter(String name) {
ITestParameter parameterType = parameterTypes.get(name);
if (parameterType == null)
throw new IllegalArgumentException(name+ " is not a valid parameter type name");
return parameterType.newInstance();
}
}
I hope this helps. Good luck!
It seems as though the general consensus of the testing community is to not test private methods. Instead, you should test private methods by testing the public methods that invoke them. However, something just doesn't feel right to me. Let's take this method for example:
/**
* Returns the base name of the output generator class. If the class is named
* Reno_OutputGenerator_HTML, this would return "HTML".
*
* #return string
*/
protected function getName()
{
$class = get_class($this);
$matches = array();
if (preg_match('/^Reno_OutputGenerator_(.+)$', $class, $matches))
{
return $matches[1];
}
else
{
throw new Reno_OutputGenerator_Exception('Class name must follow the format of Reno_OutputGenerator_<name>.');
}
}
This particular function is used in a couple of places in my class. I'd like to test both branches of the if statement in this function, which would mean for each public function I'd have to test those 2 situations plus whatever else the public method itself does.
This is what feels weird for me. If I'm testing to see if getName() throws an Exception when a certain specific condition is met, then that means that I have to know implementation details of the private method. If I have to know that, then why shouldn't I just extend the class, make the method public, and test it that way?
(BTW: If you're wondering why such a weird method exists, this is used to automagically figure out what directory this class's template files are stored in).
The way I understand unit testing, this is exactly the kind of testing I would want to do. I have always looked at unit testing as white-box testing; if there's a branch point in my code, that means I need two unit tests to address it. I think the worst case I ever wound up with was a single method with 32 permutations.
The challenge with unit-testing is that if you don't explore all the edge cases by examining your code and figuring out all the different paths, you wind up missing one or more cases and possibly introducing subtle bugs into your application.
So, no, I don't see what you're proposing as weird. The method can stay internal, and you can add an extra test case - you probably only need the one with the exception, right?
Alternatively, you could refactor the functionality into a separate object that takes your generator object and returns its name (based on the algorithm above). That would justify separating the tests, because you'd have a name-extractor object, and the output generator implementations. I'm still not sure that this would save you a lot, because you'd still have to test the output generators to make sure they were using the name extractor correctly, but it would separate your functional and testing concerns.
You could also test this function by deriving from the class in your testclass like this:
namespace TheProject
{
public class ClassUnderTest
{
protected string GetName()
{
return "The name";
}
}
}
namespace TestProject
{
[TestClass]
public class TheTest:TheProject.ClassUnderTest
{
[TestMethod]
public void TestGetName()
{
string expected = "The name";
string actual = GetName();
Assert.AreEqual(expected, actual);
}
}
}
That way you keep your method private and you don't need to refactor your code to another class.
i created a Wrapper for a C++ dll. While reading the documentation
i reached to a point using this function strcpy(StructName.strPropGetter, "A STRING");
I'm not kinda C++ guy, i can't figure how to transfer this code in C#.
My wrapper gave me this property without a setter.
Any light would be nice. Thank you
It's simply StructName.strPropGetter = "A STRING";
edit
If you mean how should you implement strPropGetter, then this is difficult wihout any information on what strPropGetter is. But it may be something like:
class StructName
{
string strPropGetter { get; set; }
}
StructName.strPropGetter = "A STRING";
(This is a literal copy of the names to make it easier to see how it relates to the original snippet of code, but obviously "strPropGetter" etc should be named something more sensible. The "Getter" in the original name possibly refers to a "get" mehod for a property, in which case, this is generated automatically by C# for the "get;" part of the property in the code above.
I can't really help much more without a better idea of what code you're looking at wrapping/converting.