Is it possible to have optional parameters in Centura 6.1?
Like:
test( boolean , hWnd... )
And how would I declare them?
You can't.
Team Developer does not support optional parameters.
Gupta TeamDeveloper v6.3 onwards supports Overloaded Constructors , allowing you to declare any number of Constructors with different parameter types. The compiler decides which constructor to use according to the parameter list you send it. See below for a simple example of calling the Constructor using 1) a Boolean parameter and then 2) a String Parameter.
Related
Try to make as described:
To convert a string to lowercase, you can call the String.ToLower()
method
let makeUpperCase s =
s.ToUpper()
Get as result
error FS0072: Lookup on object of indeterminate type based on
information prior to this program point. A type annotation may be
needed prior to this program point to constrain the type of the
object. This may allow the lookup to be resolved.
If you want to invoke members of a value that is passed as an argument to a function, you have to give F# some hint about what the type of the value is. The best way to do this is using a type annotation:
let makeUpperCase (s:string) =
s.ToUpper()
F# compiler needs this, because it cannot figure out what ToUpper method are you trying to invoke as there may be many .NET objects that have a method of this name.
If a mocked method is passed a generic type as a parameter, it is easy to generate the same response regardless of its value by using methods such as anyInt(), anyChar(), anyString(), etc.
Is it possible to do this where the parameter must be a particular type of Object?
(For example, anyCar(), anyVehicle(), etc.)
The matcher isA(Class<T> clazz) provides this functionality.
For example -
isA(Car.class), isA(Vehicle.class)
I am using a T4 to create my interface, however the only issue I am having is if my methods have optional parameters, I am not adding them to the interface.
I'm using EnvDTE to get the information and I have the CodeParameter, but do not see a way to tell it parameter has optional value.
Anyway to tell if the parameter has an optional value?
Try using CodeParameter2 instead. It has a ParameterKind property, which can be set to vsCMParameterKindOptional, and a DefaultValue property.
I am not sure whether this is the right forum to ask this question, but it refers to code, so I am asking here.
In the book "Groovy in action", section 7.1.4 (named parameters), the author says that usage of named params "crops up frequently in creating immutable classes that have some parameters that are optional".
What has immutability of the class got to do with optional parameters? I thought these 2 topics were completely orthogonal.
crops up frequently in creating immutable classes that have some parameters that are optional
the sentence above is a bit blurry as there is no such thing as "class parameters", i can only assume it relates to method/constructor parameters.
when we're talking about constructors, Groovy's named parameters make sense when its about optional parameters:
#groovy.transform.Immutable
class Person {
String firstName
String lastName
Integer age
}
def p = new Person(age: 42, lastName: 'Doe')
The above example shows how to create an immutable Person instance. The firstName is not provided as named parameter, it's optional. In fact, with named parameters it's possible to specify any parameter combo when making the constructor call without actually having to implement constructors for all combinations.
There is also the possibility of using named parameters in instance/static method calls, as shown in this blog post by Mr. Haki.
The key to that statement is that if you're dealing with an immutable class, the implication is that you have only one chance to set state - in a constructor. Normally you'd be able to manipulate an (mutable) object via setters, one-at-a-time, to build up the desired state. For an immutable, you'd have to create a ctor for every possible set of instantiation states instead, if a facility like optional params were not available. For a class with many fields, this could get messy.
This is what I am trying to do:
public void method(int myVal, string myOtherVal)
{
// doing something
}
dynamic myVar = new SomeDynamicObjectImplementer();
method(myVar.IntProperty, myVar.StringProperty);
Note that my properties are also DynamicObjects. My problem is that the TryConvert method is never called and that I get a runtime error saying the method signature is invalid.
The following is working great:
string strVar = myVar.StringProperty;
int intVar = myVar.IntProperty;
And I would like to avoid
method((int)myVar.IntProperty, (string)myVar.StringProperty);
Is it possible to override something in DynamicObject to allow this? (or something else)
Thank you
The problem is your assumption that it will try a dynamic implicit convert on arguments of an dynamic invocation to make a method call work, this is not true.
When your arguments aren't statically typed, it will use the runtime type to find the best matching method (if the runtime type matches the static rules for implicit conversion to the argument type this will work too), since your your IntProperty,StringProperty seem to be returning a DynamicObject rather than an Int and a String or something that could statically be converter implicitly, this lookup will fail.
If SomeDynamicObjectImplementer could actually return an Int for IntProperty and a String for StringProperty your method call for without casting would actually work. It's also probably a better dynamic typing practice if you data type is based on the actually type of data rather than usage using try convert. You could add actually implicit convert methods for every possible type that you could return to that returned DynamicObject type, but that could cause strange resolution issues to depending on how much you are overloading.
However, another option to keep your dynamic implementation the same is to mix a little controlled static typing in, you can use ImpromputInterface (in nuget) to put an interface on top of a dynamic object, if you do that then the TryConvert method would be called on your returned DynamicObjects.
public interface ISomeStaticInterface{
int IntProperty {get;}
string StringProperty {get;}
}
...
var myVar = new SomeDynamicObjectImplementer().ActLike<ISomeStaticInterface>();
method(myVar.IntProperty, myVar.StringProperty);
Instead of using myVar.IntProperty can't you just put them in variables first, like you already did, and then use then for your method?
so method(intVar , strVar); seems fine. At least more elegant than casting.
Of course, if you're already certain your object will have IntProperty and StringProperty, why not just make an actual object with those properties instead?
Why are you doing the cast?
method(myVar.IntProperty, myVar.StringProperty);
should compile.
If the two properties must be the types suggested by the names then they shouldn't be dynamic.