I'm wondering which bases Reference has in different situations.
For example: undefined, Object, Boolean, String, Number, Environment Record.
I will assume that the base for declaring the variable "a" will be the Environment Record. And the structure of Reference "a" will look like this:
/// Definition variable in javascript code
var a;
/// Reference structure in engine
Reference = {
Base: Environment Record, /// It's one of other cases
ReferencedName: "a",
StrictReference: false
}
I'm not saying that what I wrote correctly, I just want to know how the structures look in other types.
Related
Python has dict, doc, init and so on.
Is there something like that in Julia?
How can I know names of functions of Julia packages?
In addition to the function names (e.g. names(Gadfly)), which is used for modules. If you want to get all the attributes of the object, there are two functions for that:
fieldnames - returns a list of the fields for the object
e.g.
struct Point
x
y
end
> propertynames(Point(2,3))
(:x, :y)
propertynames - returns a list of all the properties for the object. Usually the same as fieldnames plus user-defined properties (in most cases, you should use this function instead of fieldnames)
Use the names function to get a list of all names exported by a module (as this is what I assume you are looking for). Note that the list will in particular include: functions, types, variables, and other modules. Here is an excerpt from its docstring giving you more details:
names(x::Module; all::Bool = false, imported::Bool = false)
Get an array of the names exported by a Module, excluding deprecated names. If all is true, then the list also includes non-exported names defined in the module, deprecated names, and compiler-generated names. If imported is true, then names explicitly imported from other modules are also included.
Because of the Julia design you should be aware of two issues:
some packages opt not to export names, but assume that they should be always qualified; this is the case of e.g. CSV.jl package
objects other than functions can be made callable in Julia (types are callable as constructors, variables can be turned into functors)
I would like to HTTP POST values directly as JSON to an addBook resolver already declared in my GraphQL Mutation.
However, the examples I've seen (and proven) use serialisation of parameters from JSON to SDL or re-declaration of variables in SDL to bind from a Query Variable.
Neither approach makes sense because the addBook mutation already has all parameters and validation declared. Using these approaches would lead to unnecessary query serialisation logic having to be created, debugged and maintained.
I have well-formed (schema- edited and -validated) JSON being constructed in the browser which conforms to the data of a declared GraphQLObjectType.
Can anyone explain how to avoid this unnecessary reserialisation or duplication when posting against a mutation resolver?
I've been experimenting with multiple ways of mapping a JSON data structure against the addBook mutation but can't find an example of simply sending the JSON so that property names are be bound against addBook parameter names without apparently pointless reserialisation or boilerplate.
The source code at https://github.com/cefn/graphql-gist/tree/master/mutation-map is a minimal reproducible example which demonstrates the problem. It has an addBook resolver which already has parameter names, types and nullability defined. I can't find a way to use JSON to simply POST parameters against addBook.
I'm using GraphiQL as a reference implementation to HTTP POST values.
I could write code to serialise JSON to SDL. It would end up looking like this which works through GraphiQL:
mutation {addBook(id:"4", name:"Education Course Guide", genre: "Education"){
id
}}
Alternatively I can write code to explicitly alias each parameter of addBook to a different query which then allows me to post values as a JSON query variable, also proven through GraphiQL:
mutation doAdd($id: String, $name: String!, $genre: String){
addBook(id:$id, name:$name, genre:$genre){
id
}
}
...with the query variable...
{
name: "Jonathan Livingstone Seagull",
id: "6"
}
However, I am sure there's some way to directly post this JSON against addBook, telling it to take parameters from a Query Variable. I'm imagining something like...
mutation {addBook($*){
id
}}
I would like a mutation call against addBook to succeed, taking named values from a JSON Query Variable, but without reserialisation or redeclaration of the properties to parameter names.
This boils down to schema design. Instead of having three arguments on your field
type Mutation {
addBook(id: ID, name: String!, genre: String!): Book
}
you can have a single argument that takes an input object type
type Mutation {
addBook(input: AddBookInput!): Book
}
input AddBookInput {
id: ID
name: String!
genre: String!
}
Then your query only has to provide a single variable:
mutation AddBook($input: AddBookInput!) {
addBook(input: $input) {
id
}
}
and your variables look something like:
{
"input": {
"name": "Jonathan Livingstone Seagull",
"genre": "Fable"
}
}
Variables have to be explicitly defining as part of the operation definition because GraphQL and JSON are not interchangeable. A JSON string value could be a String, an ID or some custom scalar (like DateTime) in GraphQL. The variable definitions tell GraphQL how to correctly serialize and validate the provided JSON values. Because variables can be used multiple times throughout a document, their types likewise cannot simply be inferred from the types of the arguments they are used with.
EDIT:
Variables are only declared once per document. Once declared, they may be referred to any number of times throughout the document. Imagine a query like
mutation MyMutation ($id: ID!) {
flagSomething(somethingId: $id)
addPropertyToSomething(id: $id, property: "WOW")
}
We declare the variable once and tell GraphQL it's an ID scalar and it's non-nullable (i.e. required). We then use the variable twice -- once as the value of somethingId on flagSomething and again as the value of id on addPropertyToSomething. The same variable could also be used as the value to a directive's argument too -- it's not limited to just field arguments. Notice also that nothing says the variable name has to match the field name -- this is typically only done out of convenience.
The other notable thing here is that there's two validation steps happening here.
First, GraphQL will check if the provided variable (i.e. the JSON value) can be serialized into the type specified. Since we declared the variable as non-null (using !), GraphQL will also verify the variable actually exists and is not equal to null.
GraphQL will also verify that the type you specified for the variable matches the types of the arguments where it's actually used. So an Int variable will throw if it's passed to a String argument and so on. Moreover, nullability is checked here too. So an argument that is an Int! (non-null integer) will only accept variables that are also Int!. However, an argument that is Int (i.e. nullable) will accept either Int or Int! variables.
The syntax that exists is there for a reason. The kind of syntax you're imagining would only make sense in a specific scenario where you're only querying a single root field and using all the variables as arguments to that one field and the variable names match the argument names and you don't need to dynamically set any directive arguments.
According to http://www.cocos2d-x.org/wiki/Value,
Value can handle strings as well as int, float, bool, etc.
I'm confused when I have to make a choice between using
std::string
or
Value
In what circumstances should I use Value over std::string, and vice versa??
I think you have misunderstood the Value object. As written in the documentation you linked to:
cocos2d::Value is a wrapper class for many primitives ([...] and std::string) plus [...]
So really Value is an object that wraps a bunch of other types of variables, which allows cocos2d-x to have loosely-typed structures like the ValueMap (a hash of strings to Values - where each Value can be a different type of object) and ValueVector (a list of Values).
For example, if you wanted to have a configuration hash with keys that are all strings, but with a bunch of different values - in vanilla C++, you would have to create a separate data structure for each type of value you want to save, but with Value you can just do:
unordered_map<std::string, cocos2d::Value> configuration;
configuration["numEnemies"] = Value(10);
configuration["gameTitle"] = Value("Super Mega Raiders");
It's just a mechanism to create some loose typing in C++ which is a strongly-typed language.
You can save a string in a Value with something like this:
std::string name = "Vidur";
Value nameVal = Value(name);
And then later retrieve it with:
std::string retrievedName = nameVal.asString();
If you attempt to parse a Value as the wrong type, it will throw an error in runtime, since this is isn't something that the compiler can figure out.
Do let me know if you have any questions.
I'm tring my hand in Meteor - so far, I like it :-)
However, I am trying to store a JSON object directly into miniMongo, but not getting anywhere - while I thought that was the purpose :-)
testVar = {"test":"this is from the object"}
QStore.update(
{"_id" : QT._id},
{
$set: {
"tCode" : testVar,
"name" : "verion 6"
}
}
)
in the schema of the QStore, tCode is defined as {object} which I thought would be right... where am I wrong? :-)
regards,
Paul
Assuming you're using aldeed:simple-schema and everything else is okay (which is tough to tell with only the code snippet above), it's most likely you're missing the blackbox flag in your schema definition:
blackbox
If you have a key with type Object, the properties of the object will be validated as well, so you must define all allowed properties in the schema. If this is not possible or you don't care to validate the object's properties, use the blackbox: true option to skip validation for everything within the object.
I am new on Swift, my question is where do we use and need External Parameter?
From the Apple's Swift Language Guide:
Sometimes it’s useful to name each parameter when you call a function,
to indicate the purpose of each argument you pass to the function.
If you want users of your function to provide parameter names when
they call your function, define an external parameter name for each
parameter, in addition to the local parameter name.
So, you don't "need" an external parameter name but it is a good practice to use them because they serve as documentation about the parameters at the point the method is called.
For example, without using external parameter names, you can define a join method like this:
func join(_ s1: String,_ s2: String,_ joiner: String) -> String {
return s1 + joiner + s2
}
which will then be called like this:
join("foo", "bar", ", ")
As you can see, each parameter's meaning is not very clear.
Using external parameter names, you could define the same method like below:
func join(string s1: String, toString s2: String, withJoiner joiner: String) -> String {
return s1 + joiner + s2
}
which would then force the users to call it like this:
join(string: "foo", toString: "bar", withJoiner: ", ")
You can see that it makes the meaning of the parameters, along with what the method does, much more clear.
It might seem not so important in this simple example but when defining methods that take a lot of parameters with not-so-obvious meanings, using external parameter names will make your code much more easy to understand.
Update for Swift 3:
This has become even more meaningful with the introduction of Swift 3. Consider the append(contentsOf:) method of the Array class in Swift 3:
Not having different internal and external parameter names in this case would force us to change the label contentsOf to something like string in the call site, which wouldn't read as good as the former one. Swift 3 API guidelines rely on having different internal and external parameter names to create clear and concise methods.