Implicitly define Dictionary pairs [duplicate] - actionscript-3

This question already has an answer here:
Flex dictionary literal
(1 answer)
Closed 8 years ago.
Background
Defining an Array is typically demonstrated as var array:Array = new Array(), however, this relegates array assignment to methods like array.push(value) or linear declarations like ...
array[0] = "apple"
array[1] = "orange"
Obviously, a more succinct format is an implicit declaration, where a double bracket is understood to define an array, and the index is automatically handled.
var array:Array = ["apple", "orange"];
The same works for Objects...
var obj:Object = {
"apple":"fritter",
"orange":"pie"
}
The Problem
The problem arises when trying to define a Dictionary's key:value pairs implicitly. Reading the documentation, I was shocked to only find one method on the class. The fact that it extends Object at least means for ... in are available, but that's about where the conveniences end.
Especially since we'll want to use weak keys, the one argument available to Dictionaries would need to be set to true, thereby precluding any kind of implicit definition. The same documentation outlines typical usage in the former (lengthier) format I demonstrated with arrays:
var dict:Dictionary = new Dictionary(true);
dict[key] = "Letters";
That's just not going to fly for complicated structures.
[ redacted with argument ]
Because the docs for both Array & Object never actually explain implicit declarations, I can't help but imagine there might be a way to do so with Dictionaries. Anyone know?
I'm thinking now my only option is to come up with some kind of method which maps a complex object tree to a dictionary... which is dumb, since it'd be faster to just use the long method first demonstrated.

First of all, even if you write the code with Object and don't quote up strings as in original question, you'll not receive the expected results. And if you are attempting to use an object as a key in with statement, the compiler will be confused whether you want dict[obj] or just obj to be assigned a value. So, if you are adding a property to an Object or Dictionary, use the brackets syntax:
obj["apple"]="fritter";
dict[obj]="bar";
Etc.

Related

Understanding NewtonSoft in PowerShell

I making a foray into the world of JSON parsing and NewtonSoft and I'm confused, to say the least.
Take the below PowerShell script:
$json = #"
{
"Array1": [
"I am string 1 from array1",
"I am string 2 from array1"
],
"Array2": [
{
"Array2Object1Str1": "Object in list, string 1",
"Array2Object1Str2": "Object in list, string 2"
}
]
}
"#
#The newtonSoft way
$nsObj = [Newtonsoft.Json.JsonConvert]::DeserializeObject($json, [Newtonsoft.Json.Linq.JObject])
$nsObj.GetType().fullname #Type = Newtonsoft.Json.Linq.JObject
$nsObj[0] #Returns nothing. Why?
$nsObj.Array1 #Again nothing. Maybe because it contains no key:value pairs?
$nsObj.Array2 #This does return, maybe because has object with kv pairs
$nsObj.Array2[0].Array2Object1Str1 #Returns nothing. Why? but...
$nsObj.Array2[0].Array2Object1Str1.ToString() #Cool. I get the string this way.
$nsObj.Array2[0] #1st object has a Path property of "Array2[0].Array2Object1Str1" Great!
foreach( $o in $nsObj.Array2[0].GetEnumerator() ){
"Path is: $($o.Path)"
"Parent is: $($o.Parent)"
} #??? Why can't I see the Path property like when just output $nsObj.Array2[0] ???
#How can I find out what the root parent (Array2) is for a property? Is property even the right word?
I'd like to be able to find the name of the root parent for any given position. So above, I'd like to know that the item I'm looking at (Array2Object1Str1) belongs to the Array2 root parent.
I think I'm not understanding some fundamentals here. Is it possible to determine the root parent? Also, any help in understanding my comments in the script would be great. Namely why I can't return things like path or parent, but can see it when I debug in VSCode.
dbc's answer contains helpful background information, and makes it clear that calling the NewtonSoft Json.NET library from PowerShell is cumbersome.
Given PowerShell's built-in support for JSON parsing - via the ConvertFrom-Json and ConvertTo-Json cmdlets - there is usually no reason to resort to third-party libraries (directly[1]), except in the following cases:
When performance is paramount.
When the limitations of PowerShell's JSON parsing must be overcome (lack of support for empty key names and keys that differ in letter case only).
When you need to work with the Json.NET types and their methods rather than with the method-less "property-bag" [pscustomobject] instances ConvertFrom-Json constructs.
While working with NewtonSoft's Json.NET directly in PowerShell is awkward, it is manageable, if you observe a few rules:
Lack of visible output doesn't necessarily mean that there isn't any output at all:
Due to a bug in PowerShell (as of v7.0.0-preview.4), [JValue] instances and [JProperty] instances containing them produce no visible output by default; access their (strongly typed) .Value property instead (e.g., $nsObj.Array1[0].Value or $nsProp.Value.Value (sic))
To output the string representation of a [JObject] / [JArray] / [JProperty] / [JValue] instance, do not rely on output as-is (e.g, $nsObj), use explicit stringification with .ToString() (e.g., $nsObj.ToString()); while string interpolation (e.g., "$nsObj") does generally work, it doesn't with [JValue] instances, due to the above-mentioned bug.
[JObject] and [JArray] objects by default show a list of their elements' instance properties (implied Format-List applied to the enumeration of the objects); you can use the Format-* cmdlets to shape output; e.g., $nsObj | Format-Table Path, Type.
Due to another bug (which may have the same root cause), as of PowerShell Core 7.0.0-preview.4, default output for [JObject] instances is actually broken in cases where the input JSON contains an array (prints error format-default : Target type System.Collections.IEnumerator is not a value type or a non-abstract class. (Parameter 'targetType')).
To numerically index into a [JObject] instance, i.e. to access properties by index rather than by name, use the following idiom: #($nsObj)[<n>], where <n> is the numerical index of interest.
$nsObj[<n>] actually should work, because, unlike C#, PowerShell exposes members implemented via interfaces as directly callable type members, so the numeric indexer that JObject implements via the IList<JToken> interface should be accessible, but isn't, presumably due to this bug (as of PowerShell Core 7.0.0-preview.4).
The workaround based on #(...), PowerShell's array-subexpression operator, forces enumeration of a [JObject] instance to yield an array of its [JProperty] members, which can then be accessed by index; note that this approach is simple, but not efficient, because enumeration and construction of an aux. array occurs; however, given that a single JSON object (as opposed to an array) typically doesn't have large numbers of properties, this is unlikely to matter in practice.
A reflection-based solution that accesses the IList<JToken> interface's numeric indexer is possible, but may even be slower.
Note that additional .Value-based access may again be needed to print the result (or to extract the strongly typed property value).
Generally, do not use the .GetEnumerator() method; [JObject] and [JArray] instances are directly enumerable.
Keep in mind that PowerShell may automatically enumerate such instances in contexts where you don't expect it, notably in the pipeline; notably, when you send a [JObject] to the pipeline, it is its constituent [JProperty]s that are sent instead, individually.
Use something like #($nsObj.Array1).Value to extract the values of an array of primitive JSON values (strings, numbers, ...) - i.e, [JValue] instances - as an array.
The following demonstrates these techniques in context:
$json = #"
{
"Array1": [
"I am string 1 from array1",
"I am string 2 from array1",
],
"Array2": [
{
"Array2Object1Str1": "Object in list, string 1",
"Array2Object1Str2": "Object in list, string 2"
}
]
}
"#
# Deserialize the JSON text into a hierarchy of nested objects.
# Note: You can omit the target type to let Newtonsoft.Json infer a suitable one.
$nsObj = [Newtonsoft.Json.JsonConvert]::DeserializeObject($json)
# Alternatively, you could more simply use:
# $nsObj = [Newtonsoft.Json.Linq.JObject]::Parse($json)
# Access the 1st property *as a whole* by *index* (index 0).
#($nsObj)[0].ToString()
# Ditto, with (the typically used) access by property *name*.
$nsObj.Array1.ToString()
# Access a property *value* by name.
$nsObj.Array1[0].Value
# Get an *array* of the *values* in .Array1.
# Note: This assumes that the array elements are JSON primitives ([JValue] instances.
#($nsObj.Array1).Value
# Access a property value of the object contained in .Array2's first element by name:
$nsObj.Array2[0].Array2Object1Str1.Value
# Enumerate the properties of the object contained in .Array2's first element
# Do NOT use .GetEnumerator() here - enumerate the array *itself*
foreach($o in $nsObj.Array2[0]){
"Path is: $($o.Path)"
"Parent is: $($o.Parent.ToString())"
}
[1] PowerShell Core - but not Windows PowerShell - currently (v7) actually uses NewtonSoft's Json.NET behind the scenes.
You have a few separate questions here:
$nsObj[0] #Returns nothing. Why?
This is because nsObj corresponds to a JSON object, and, as explained in this answer to How to get first key from JObject?, JObject does not directly support accessing properties by integer index (rather than property name).
JObject does, however, implement IList<JToken> explicitly so if you could upcast nsObj to such a list you could access properties by index -- but apparently it's not straightforward in PowerShell to call an explicitly implemented method. As explained in the answers to How can I call explicitly implemented interface method from PowerShell? it's necessary to do this via reflection.
First, define the following function:
Function ChildAt([Newtonsoft.Json.Linq.JContainer]$arg1, [int]$arg2)
{
$property = [System.Collections.Generic.IList[Newtonsoft.Json.Linq.JToken]].GetProperty("Item")
$item = $property.GetValue($nsObj, #([System.Object]$arg2))
return $item
}
And then you can do:
$firstItem = ChildAt $nsObj 0
Try it online here.
#??? Why can't I see the Path property like when just output $nsObj.Array2[0] ???
The problem here is that JObject.GetEnumerator() does not return what you think it does. Your code assumes it returns the JToken children of the object, when in fact it is declared as
public IEnumerator<KeyValuePair<string, JToken>> GetEnumerator()
Since KeyValuePair<string, JToken> doesn't have the properties Path or Parent your output method fails.
JObject does implement interfaces like IList<JToken> and IEnumerable<JToken>, but it does so explicitly, and as mentioned above calling the relevant GetEnumerator() methods would require reflection.
Instead, use the base class method JContainer.Children(). This method works for both JArray and JObject and returns the immediate children in document order:
foreach( $o in $nsObj.Array2[0].Children() ){
"Path is: $($o.Path)"
"Parent is: $($o.Parent)"
}
Try it online here.
$nsObj.Array1 #Again nothing. Maybe because it contains no key:value pairs?
Actually this does return the value of Array1, if I do
$nsObj.Array1.ToString()
the JSON corresponding to the value of Array1 is displayed. The real issue seems to be that PowerShell doesn't know how to automatically print a JArray with JValue contents -- or even a simple, standalone JValue. If I do:
$jvalue = New-Object Newtonsoft.Json.Linq.JValue 'my jvalue value'
'$jvalue' #Nothing output
$jvalue
'$jvalue.ToString()' #my jvalue value
$jvalue.ToString()
Then the output is:
$jvalue
$jvalue.ToString()
my jvalue value
Try it online here and, relatedly, here.
Thus the lesson is: when printing a JToken hierarchy in PowerShell, always use ToString().
As to why printing a JObject produces some output while printing a JArray does not, I can only speculate. JToken implements the interface IDynamicMetaObjectProvider which is also implemented by PSObject; possibly something about the details of how this is implemented for JObject but not JValue or JArray are compatible with PowerShell's information printing code.

Add/Remove elements in a JSON Array in Scala/Play

I have a pretty complex JSON object that contains, among other things, some JSON arrays that I need to update, removing and adding elements.
To do that I'm trying to use a JsPath that point directly to the object inside the array that I need to remove, something like:
/priceLists(1)/sections(0)/items(0)
to remove the element I tried to use json.prune and it doesn't work, I get this error: error.expected.jsobject
Would would be the best way to do that?
Your question is lacking a precise context (i.e., structure of your json data), but let's do with what we have.
The error message you get is clear, you can only call prune on a json object, to prune one of its values. You can't use it to prune an element of a json array.
I can only advise you to use json.update, stating that like prune, update only works on json objects. In the body of the update, work on your arrays as you usually do with scala/java data types.
__.json.update(__.reads[JsArray].map { jsArray =>
val removedElement = JsArray(jsArray.value.filter(_ == ???))
val addedElement = removedElement :+ JsBoolean(true)
addedElement
})

Is it allowed to use numbers as keys in object literal?

The following examples can be compiled, but I'm not sure if it's documented anywhere:
var o:Object = { 1: 2, 3: 4 };
Can I safely use this in my code?
P.S. I know that I can just use Arrays instead of objects like this one, but sometimes { key: value } is clearer than array initialization.
Yes, sure, you can. The use case for example is {id:valueObject} hash map. Key here automatically converts to String.

What exactly is a hash in regards to JSON?

I am learning JSON, but I found out that you can put what are called "hashes" into JSON as well? Where can I find out what a hash is? Or could you explain to me what a hash is? Also, what's a hashmap? I have experience in C++ and C#, and I am learning JS, Jquery, and JSON.
A Hash is a sparse array that uses arbitrary strings/objects (depending on the implementation, this varies across programming languages) rather than plain integers as keys.
In Javascript, any Object is technically a hash (also referred to as a Dictionary, Associative-Array, etc).
Examples:
var myObj = {}; // Same as = new Object();
myObj['foo'] = 'bar';
var myArr = []; // Same as = new Array();
myArr[0] = 'foo';
myArr[1] = 'bar';
myArr['blah'] = 'baz'; // This will work, but is not recommended.
Now, since JSON is basically using JS constructs and some strict guidelines to define portable data, the equivalent to myObj above would be:
{ "foo" : "bar" };
Hope this helps.
Hash = dictionary.
A hash:
{ "key1": "value1", "key2": "value2" }
JSON supports dictionary type elements. People may refer to these as hash tables, which are a type of data structure.
Referring to JSON dictionaries as hash tables would be technically incorrect, however, as there is no particular data structure implementation associated with the JSON data itself.
A hash is a random looking number which is generated from a piece of data and always the same for the same input. For example if you download files from some websites they will provide a hash of the data so you can verify your download is not corrupted (which would change the hash).
Another application of hashes is in a hash table (or hash map). This is a very fast associative data structure where the hashes are used to index into an array. std::unorderd_map in C++ is an example of this.
You could store a hash in JSON as a string for example something like "AB34F553" and use this to verify data.
On json.org, a JSON "object" is "a collection of name/value pairs. In various languages, this is realized as an object, record, struct, dictionary, hash table, keyed list, or associative array."
Using the ambiguous term "hash" for a JSON object is confusing. "Hash" is indeed used in the wild as short-hand for: hash map, dictionary, key-value structure, etc. But it is also short-hand for: the hash value that is computed by a hash function.

Repeated Keyword Value in JSON

On JSON.org the essential data structures that JSON represents are given as
A collection of name/value pairs, and
An ordered list of values.
I have not been able to find anywhere whether a second member having the same name as one already parsed into the current object should (a) throw an exception or (b) replace the existing member.
Is this specified anywhere?
What do existing parsers do with repeated names?
EDIT: I am looking to define correct behavior for my parser.
JSON is simply a subset of the object literal notation of JavaScript and as such, is constrained by the same rules - the latest value for repeated keys will override any previously assigned value for that key, within the specific object. Think in terms of assigning a value to an object property; A later assignment will override an earlier one.
To demonstrate this, I have set up an example here. The code is displayed on the page, and as can be seen, the messagebox has the name 'Barney' in it.
Code here -
$(function() {
$('#myButton').click(function(e)
{
var myJsonString = "Person = {'firstName':'Fred','lastName':'Flintstone','firstName':'Barney'}";
eval("(" + myJsonString + ")");
alert(Person.firstName);
});
});
By the Way, I have used eval() here for ease of use. I would recommend using a JSON parser instead of eval() due to security issues.
They last name found by the parser is replaced by the new one. It doesn't throw an expection.
It is simply a Javascript syntax thing.
var json = {};
// lets augment the object
json.one = 1;
json.one = 2; // it gets replaced
I am pretty sure that both behaviors you list would be accepted, along with others (use the first one, use any of them). :-)
That is, such behavior is undefined from JSON specification POV.
As a practical matter, implementations I have used do either one of suggestions you mentioned, or "use the first one".
So no, I would not count on specific behavior given that tools can choose what to do.
Because JSON is simply a subset of Javascript, it largely depends upon the Javascript specification. I don't know personally what the answer is, but I would highly suggest not relying upon the behavior if at all possible.