Is there a way to execute a literal such as,
UseValueKey = ExecuteMethod("Date()")
I want to have the variable UseValueKey return the actual date.
I am using VBA.
Any ideas?
I haven't done any VBA coding for several years, but I recall that Access VBA had an Eval() method that could be used to evaluate code represented as a string.
This article gives an example of its usage.
You can try the Eval function.
If, as indicated in the question comments, the function name is known and can be delivered as a method on a class, try looking at
CallByName object, routine, callType
where callType indicates whether the called routine is a property Get/Let/Set or a Method.
It feels a lot less kludgey (and somewhat better controlled) than fooling with code evaluation, where you may be leaving yourself open to, er, unexpected consequences...
Perhaps I'm not exactly following you, but you should be able to use
Date
for example
UseValueKey = date
Related
You can define a function to pass its keyword arguments to inner functions like this:
function example(data;xcol,ycol,kwargs...)
DoSomething(; spec=:EX, x=xcol, y=ycol, kwargs...)
end
Now, the function DoSomething accepts many arguments, such as color. This works for functions, but I'd like to do this with a macro from VegaLite.jl:
function example(data;xcol,ycol,kwargs...)
#vlplot(data=data,mark=:point, x=xcol, y=ycol,kwargs...)
end
example(df,xcol=:Miles_per_Gallon, ycol=:Horsepower, color=:Origin)
Note that the code above does not work.
So the answer here is... it's tricky. And in fact, in general, this isn't possible unless the macro itself supports it.
See, macros do their transformations at parse time — and often will exploit what you've actually written to mean something different and special. For example, #vlplot will specially handle and support JSON-like {} syntaxes. These aren't valid Julia code and can't be passed to a function you define (like example)!
Now, it's tempting to see this and think, ok, let's make that outer example thing into a macro, too! But it's not that easy. I'm not sure it's possible to have a general answer that will always pass the arguments appropriately and get the hygiene correct. I'm pretty sure you need to know something about how the macro you're calling handles its arguments.
you need to add ; before kwargs to signal they are kwargs not positional arguments e.g.:
DoSomething(;spec=:EX, x=xcol, y=ycol, kwargs...)
(this is the answer for DoSomething being a function as this was the original formulation of the question)
So I've been Googling function arguments and I would like to understand arguments better.
I am new to as3, to summarize arguments with my current knowledge, I would say they are like temporary variables? I don't fully get why you add parameters which are names that can be any value? Then you like call these parameters later and their order magically replace these parameters, but why? I'm missing some understanding here to fully grasp their use. Why make parameters in a function and then add the values later? If I'm even saying that right.
function name( applepie, sugar, healthyfood)
name( 1,2,3)
What was the point?
Also I haven't found a syntax book that describes what every symbol does yet that I can just search like () and it describes it, I heard some just use Google, but the results I got weren't very fruitful. Hence why I'm here asking. Personally I don't want to continue on until I fully grasps the use of (). I also tried Adobe website search but that didn't work out well either, was a good amount of searches trust me....
A function is a piece of code that can be reused many times in different contexts. You pass arguments to a function to tell the function something about the context in which it is being called; as a trivial example, when you call the print() function you must specify what you want the function to print. In your example name(applepie, sugar, healthyfood) the function should use the value supplied in place of each argument somewhere in its body, because the function doesn't know what values it will be passed, in the body of the function definition you use the names you chose (which should be descriptive) to refer to the values which will be passed in later and which will presumably be different each time it is called.
The parentheses are used for delimiting different semantic elements, in this case they are telling the interpreter where the argument list starts and stops.
I work with a BASIC programming language and have found it useful to write functions that rely on their output as a parameter. Such as
inOut = someFunction(inOut)
I'd like to call this a recursive function. but it doesn't seem right because it is not calling itself. Can someone tell me what the name of this type of function is and if the parameter/return has a special name?
Thanks!!
This is an ordinary function as any other. The thing you show is called reassingment. You can rename inOut on the left with newinOut and it will not change anything... there is absolutely nothing special about the function, it's a naming pattern, that's all.
In many languages (including VB, but not sure about classic BASIC) there's something called passing parameter by reference. It's not exactly what you posted, but rather simple
someFunction(inOut)
parameter is passed into the function, changed there and the change persists outside the function
I was looking at some code of a fellow developer, and almost cried. In the method definition there are 12 arguments. From my experience..this isn't good. If it were me, I would have sent in an object of some sort.
Is there another / more preferred way to do this (in other words, what's the best way to fix this and explain why)?
public long Save (
String today,
String name,
String desc,
int ID,
String otherNm,
DateTime dt,
int status,
String periodID,
String otherDt,
String submittedDt
)
ignore my poor variable names - they are examples
It highly depends on the language.
In a language without compile-time typechecking (e.g. python, javascript, etc.) you should use keyword arguments (common in python: you can access them like a dictionary passed in as an argument) or objects/dictionaries you manually pass in as arguments (common in javascript).
However the "argument hell" you described is sometimes "the right way to do things" for certain languages with compile-time typechecking, because using objects will obfuscate the semantics from the typechecker. The solution then would be to use a better language with compile-time typechecking which allows pattern-matching of objects as arguments.
Yes, use objects. Also, the function is probably doing too much if it needs all of this information, so use smaller functions.
Use objects.
class User { ... }
User user = ...
Save(user);
It decision provides easy way for adding new parameters.
It depends on how complex the function is. If it does something non-trivial with each of those arguments, it should probably be split. If it just passes them through, they should probably be collected in an object. But if it just creates a row in a table, it's not really big deal. It's less of a deal if your language supports keyword arguments.
I imagine the issue you're experiencing is being able to look at the method call and know what argument is receiving what value. This is a pernicious problem in a language like Java, which lacks something like keyword arguments or JSON hashes to pass named arguments.
In this situation, the Builder pattern is a useful solution. It's more objects, three total, but leads to more comprehensible code for the problem you're describing. So the three objects in this case would be as such:
Thing: stateful entity, typically immutable (i.e. getters only)
ThingBuilder: factory class, creates a Thing entity and sets its values.
ThingDAO: not necessary for using the Builder pattern, but addresses your question.
Interaction
/*
ThingBuilder is a static inner class of Thing, where each of its
"set" method calls returns the ThingBuilder instance being worked with
while the final "build()" call returns the instantiated Thing instance.
*/
Thing thing = Thing.createBuilder().
.setToday("2012/04/01")
.setName("Example")
// ...etc...
.build();
// the Thing instance as get methods for each property
thing.getName();
// get your reference to thingDAO however it's done
thingDAO.save(thing);
The result is you get named arguments and an immutable instance.
How do you guys avoid keyword conflicts in your language?
For example, I'm creating a class (VB 2008) to hold all the configuration variables for some reports we generate. Naturally, one of the variables is "Date". And of course you can't have anything named the same as a keyword. In VB 2008 you do have the option of surrounding a conflicting word with []'s and fix it but I've always seen that as a hack. Any suggestions? What are your names to get around common keywords?
Code to help visualize...
Dim m_Title As String
Dim m_Date As String
Public Property Title() As String
Get
Return m_Title
End Get
Set(ByVal value As String)
m_Title = value
End Set
End Property
Public Property [Date]() As String
Get
End Get
Set(ByVal value As String)
End Set
End Property
Probably think about more specific nature of the variable?
From your example, the "Date" can be "Created Date" or "Posted Date" or anything else. If you find your variable names too trivial, you may be oversimplifying (or even obfuscating) your code. Help your coworkers by creating a clear but concise variable names.
Don't look at [Date] as a hack; if your property represents a date, it should be called Date. Use the tools you have available to get the job done. Personally I feel that properties that have the names they do only to get around such conflicts are more of a hack, since you will get to deal with it every time you use the property.
misspell your variable names!
On .NET, it is reasonable to consider the Common Language Specification (CLS) as the lowest common denominator that you should cater to. This is documented in ECMA-335 "Common Language
Infrastructure (CLI) Partitions I to VI". Here's what it says specifically about names; a note in CLS Rule #4 (8.5.1 "Valid names"):
CLS (consumer): Need not consume types that violate CLS Rule 4, but shall have a mechanism to allow access to named items that use one of its own keywords as the name.
So no, it's not really a hack, but a definite rule. The reason why it's there is that, as .NET is extensible as far as languages targeting it go, you can never avoid name clashes. If you cover C#, there's VB. If you cover C# and VB, there's C++/CLI. If you cover all those, there's F# and Delphi Prism. And so on. Hence why it is mandated by CLS that languages provide a way to escape their keywords as identifiers; and all languages I've listed provide some way to do so (and thus are compliant CLS consumers).
In general, it is still considered good manners to avoid clashes with either C# or VB non-context keywords, mainly because those two languages are the most popular by a very large margin. For example, it is the reason why it's HashSet and not just Set - the latter is a VB keyword. The full listings are:
C# keywords
VB keywords
Most languages have something to escape any reserved words. C# has # so you can use #class as an argument name (something MVC adopters are learning).
If the domain states that a certain word be used to describe it then that is what the escaping of reserved words is there for. I wouldn't be afraid to escape reserved words to get my model close to the domain even if it means more typing - the clarity is worth it!
To avoid naming conflicts with keywords, I simply don't use keywords.
In your case, Date. Date of what? If I had to maintain your application that would probably be the first thing I'd ask. The great thing about keywords is that they're completely generic, something a variable name should never be.
There is no silver bullet, but modern languages help a lot with better abilities to manage namespaces.
In my case, I curse the fact that C has an 'index' command.
"Date_" or "_Date".
This is one question where Perl dodges the question entirely.
Variables always have one of $%#*&, the only things that can conflict are Globs/Handles, and subroutines.
Even that isn't much of a problem because Globs/Handles aren't used very much any more.
Subroutines and keywords are very much the same in Perl. If you need to get at the built-in subroutine/keyword you can get at it by appending CORE::, for example CORE::dump.
Really I think the only keywords you would have a problem with are sub, my, local, and 'our', because those keywords are parsed very early in parser. Note that you can still create a sub with those names, it just won't work without specifying the full name, or from a blessed reference, or with a symbolic reference.
{
package test;
sub my{ print "'my' called using $_[-1]\n" };
sub new{ bless {}, $_[0] };
sub sub{ print "'sub' called using $_[-1]\n" };
sub symbolic{
*{__PACKAGE__.'::'.$_[1]}{CODE}->('symbolic reference');
}
my $var; # notice this doesn't call test::my()
}
package main;
my $test = test->new;
# Called from a blessed reference
$test->my('blessed reference');
$test->sub('blessed reference');
print "\n";
# Called using the full name
test::my('full name');
test::sub('full name');
print "\n";
# Called using a symbolic reference
$test->symbolic('my');
$test->symbolic('sub');
Output:
'my' called using blessed reference
'sub' called using blessed reference
'my' called using full name
'sub' called using full name
'my' called using symbolic reference
'sub' called using symbolic reference