If I setup optional parameters on a method in a VB.NET class, are the optional parameters supplied by the caller or the called method?
In C++, it is supplied by the called method.
In C#, it is supplied by the caller method.
Wondering how it worked in VB.NET.
Caller.
Another caveat C# folks might not know about is that the C# version of
optional parameters suffers from the same limitations of the VB
version (which, by the way, has been in VB since VS 2002). Namely,
the optional parameter value is a compiler trick, where the optional
parameter value is not compiled into the method called, but instead
into the caller.
Read more here: Caveats Of C# 4-0 optional parameters
By the caller. There is no universal value for "this argument was not specified" without drastically changing the method signature so the callee can't reliably tell that the argument was not supplied. It is the compiler that digs out the default value from the assembly metadata and uses it at the call site.
Related
I'm wondering about the definition of a call-by-value EXPORTING argument of an ABAP method call.
The SAP Help Portal states that EXPORTING parameters can be defined call-by-value (and call by reference). It does not give a precise definition of how this parameter type is handled. Instead, it states
For precise details of the relevant ABAP statements, refer to the
corresponding keyword documentation in the ABAP Editor.
Now, the ABAP Keyword Documentation of the SAP editor does not mention pass-by-value for EXPORTING. (It does mention pass-by-value for IMPORTING and CHANGING).
I can guess the meaning of pass-by-value EXPORTING. But I want to read the definition. From FORM/PERFORM, I know that details can be subtle. Could you point me to an official description of this case?
I'm not sure in what way the details can be subtle even when using FORMs - but anyway, it's in the documentation:
There are two ways in which parameters can be passed: pass by
reference and pass by value. Pass by value is selected in the Function
Builder by selecting pass by value, and in the above syntax, differs
from pass by reference by the specification of VALUE( ).
In pass by reference, the formal parameter points directly to the actual parameter, so that changes to the formal parameters have an
immediate effect on the actual parameter.
In pass by value, when the function module is called, the formal parameter is created as a copy of the actual parameter (in IMPORTING
and CHANGING parameters), or initial (in EXPORTING parameters) in
the stack. In CHANGING and EXPORTING parameters, the formal
parameter is copied to the actual parameter when returning from the
function module.
I am reviewing some code and I realized I don't remember the correct terminology for something. I believe if I had the following code
pnlOne.Visible = False
Would the "visible" part be considered a method, function, or what? I am learning VB alongside JavaScript, and in JS it would be a method. Is it the same for vb?
In VB.net, that is a "property". Properties in VB.net and C# as essentially glorified methods for getting and setting a value. (They actually compile down to something like get_Visible and set_Visible methods.)
pnlOne is an instance of a class and Visible is its property
Visible could be either ..
a Property; or
a Field (called "Member Variable" in VB)
.. depending on how it is declared. Both Properties and Fields are specializations of "Members"1. See Differences Between Properties and Variables in Visual Basic.
I suspect Visible is a Property in this case, and it will be for all standard Control types .. however, to verify this either way requires knowledge of the Type of the object named by pnlOne.
1
Methods (or "Sub/Function Procedures") are a different kind of Member and it is not appropriate to call either a Property or Field a "Function" or a "Method". (Note: various references inconsistently make a distinction between a Method and a Procedure; in VB.NET they an be thought of as synonyms.)
Nit: the correct term in JavaScript would be property; properties can evaluate to function-objects and can thus also can be considered methods when they do so - usually when this is used meaningfully. In any case, the code would have to be different (e.g. jsObj.set_Visible(true)) if a method was used.
How do I send parameters in smalltalk:
Pass-by-Value
Pass-by-Result
Pass-by-Value-result
Pass-by-References
Pass-by-Name
You can safely assume that all parameters in smalltalk are passed by reference.
There's only one exception for immediate object (smallintegers) which are passed by value,
but its an implementation detail (different implementations could have different kinds of immediate object classes).
AFAK, Smallscript Smalltalk uses pass-by-value as default unless you use the & sign for pass by reference just like C++, there is more information on this here.
But traditionally Smalltalk uses pass by reference as mentioned here and here.
I have to upgrade a legacy VB6 app to VB.NET; this app uses a function call from a .dll that takes a memory address as one of it's parameters. The VB6 app does this with the VarPtr() function, but this function does not exist in .NET. How do I retrieve the memory location of a variable in .NET?
-Edit1
For example
aVariable1 = aFunctionCall(VarPtr(aVariable2))
-Edit2
The exact function call is in a DLL called FTD2XX.DLL and the exact call is
FT_STATUS = FT_ListDevices(arg1, arg2, _
FT_LIST_BY_INDEX or FT_OPEN_BY_SERIAL_NUMBER)
Trying to pass addresses of something in managed code (.NET) to an unmanaged DLL might not be the best plan. VB6 and VB.NET don't have a lot in common beyond similar syntax and a similar sounding name. You may need to to pin the memory before passing an address. You will need to look into platform invoke: http://msdn.microsoft.com/en-us/library/aa288468(VS.71).aspx
It is automatic when you declare the external function with the Declare keyword. All you have to do is declare the argument with ByRef. That forces the P/Invoke marshaller to pass a pointer to the native code. Same thing as VarPtr. Only if you pass ByVal do you have to explicitly convert the passed argument to a pointer.
In VB.NET, which is better to use: function overloading or default parameters?
if the parameters are optional (i.e. the overloads are a subset of the parameters that the full procedure signature accepts) then default or optional parameters would make more sense.
If the overload is allowing a different type for the parameter or is a semantically different parameter that will be interpreted differently by the routine then overloads would make more sense.
Is the code going to be used by other languages? If so, that swings the balance towards overloads while still bearing Hamish's answer in mind. In particular, C# doesn't support optional parameters - yet...
Admittedly this wouldn't actually prevent someone using your code from C#, it just might be a pain for them.
If there are a lot of parameters and they logically represent something, you might want to consider encapsulating them together, in the same way that Process works with ProcessStartInfo. That's particularly nice from C# due to object initializers.
If this is for construction, you might also consider the builder pattern as a variant of this. For instance, in Protocol Buffers I can do something like:
Person jon = new Person.Builder { Name="Jon", Age=32,
Spouse="Holly", Kids=3 }.Build();
which ends up being very readable while still creating a person in one go (in one expression, and without having to mutate the person itself - indeed the message type is immutable; it's only the builder which isn't).
FYI
If you want to add a parameter to a function or method that is called from other assemblies, then:
You can overload by making an additional function with the extra parameter.
Or you can add an optional parameter, BUT: You have to recompile all of the assemblies that call this function, even if they don't need to use the new optional parameter! This is not usually what people expect (expecially those used to how VB6 works). Basically, you can't slip in a new optional parameter to a function and expect it to be totally backwards compatible. Also, as I understand it, if you change what the default value is, you need to rebuild all calling assemblies for the change to work.