JSONPath seems to be a popular syntax to get XPath-like searching inside JSON data. And it has been repeatedly asked whether JSONPath supports navigation to a parent (see here and here).
My question is whether there is a good reason why it has not been suggested from the start, even though it is explicitly mentioned as unsupported. Is there some syntactic reason from JavaScript? Or is there some general workaround that I am missing?
This specification was written up on a blog; AFAIK, it is not part of any ongoing committee standardization.
However, to meet the need for parent accessors (and other features), at least one implementation, JSONPath-plus which is a superset of the original spec, allows for accessing parents through a number of means (see the README docs).
Disclaimer: I am involved in working on this implementation.
Related
I struggled with this for hours before finding out that you have to use from_ instead of from when using gremlin javascript.
After digging through the source code I finally found out that the code is using from_ instead of from (see code). Since I'm a newbie this comes off as strange because its counterpart to is still to (and not to_, see code here)
I googled everywhere but couldn't find the reason why this works this way, and feel uneasy about using the underscore version since most of the times underscores denote private methods that users should not really trust.
Also, is there an official documentation page for gremlin javascript somewhere I'm missing? I'm concerned I may run into these problems in the future and there's not really an official documentation for the JavaScript version and I may need to go through the same struggle. I like gremlin, but if the JavaScript version is not stable and should not be used, I might as well look into other alternatives than Tinkerpop suites.
Gremlin Language Variants (GLVs) are given some latitude in terms of how they implement the Gremlin language so that it feels as close to the syntax and programming idioms of the native language and thus avoid too much pollution from Java. In other words, if you're using gremlin-javascript it should feel like your coding in JS and not Java. So, you will see slight differences among GLVs from time to time.
So, with respect to from_ specifically, we typically use an underscore when we have a conflict in a native language with a reserved keyword. In Java from is fully acceptable, but in other languages it is not. For Javascript, from is currently not a reserved word, but we are preparing for the eventual form of import ... from which is coming in the future.
As for documentation, I'm not aware of too much more than what you have already found on the TinkerPop web site. We hope to have more examples and information available in our next release.
I was presented with this argument when fixing a bug related to implicit casting and speaking to the developer who told me:
If you use Closure, then you do not need absolute equality. Any value would be typed, therefor you don't need to worry about implicit casts.
My response was, that's dicey. You're making a lot of assumptions; Closure does not alter JavaScript, it's primarily a labyrinthine super layer (aside: probably a moot one, now that we have TypeScript).
Anyway, if one of these implicit things does slip by because the annotations don't resolve perfectly for some reason, you can end up with a tough bug (which is what happened; it got assigned to me because I guess the other dev didn't think it could be the problem).
I got responses of, "well if that dev had properly typed that object and this wasn't just an object and..."
Or...you could just protect against this sort of thing easily by using three equal signs instead of two. Use an assertion or console log to check the condition if necessary. Don't just leave it hanging out there.
Anyway what do you think; if you're using Closure, should you still observe the general best practice of using absolute equality in your JS code?
I know this leads to a wider conversation as well (e.g. Java 8's "optional" being "totally useless"), curious in the context of Closure though.
Question is a bit vague, code example would have helped. But yes, closure does not necessarily type every object and variable. I always use === unless there is a specific reason not to.
I've been using Object as a way to have a generic associative array (map/dictionary) since AS3/Flex seems to be very limited in this regard. But I really don't like it coming from a C++/Java/C# background. Is there a better way, some standard class I've not come across... is this even considered good/bad in AS3?
Yes, Actionscript uses Object as a generic associative container and is considered the standard way of doing this.
There is also a Dictionary class available, flash.utils.Dictionary.
The difference is that Dictionary can use any value as a key, including objects, while Object uses string keys. For most uses, Object is preferred as it is faster and covers the majority of use cases.
You can see the details on Object here: http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/Object.html
and Dictionary here: http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/utils/Dictionary.html
and the differences between them here: http://livedocs.adobe.com/flex/3/html/help.html?content=10_Lists_of_data_4.html
I'm afraid there's no native alternative to Object or Dictionary for maps and other structures. As for standard, well, it depends on how one defines standard, but there are a couple of known libraries that you might like to check out if you look for Java style collections.
Like this one:
http://sibirjak.com/blog/collections/as3commons-collections/
Also, you could take a look at this question, that has links to a couple of ds libraries (including the above one).
Collections in Adobe Flex
I wouldn't say using Objects is either good or bad practice. In the general case they are faster than any Actionscript alternative (since they are native), but less featured. Sometimes the provided functionality is good enough. Sometimes, it's a bit bare-bones, so something more structured could help you getting rid of lower level details in your code and focusing in your "domain logic", so to speak.
In the end, all of these libraries implement their data structures through Objects, Dictionaries and Arrays (or Vectors). So, if the native objects are fine for your needs, I'd say go with them. On the other hand, if you find yourself basically re-writting, say, an ad-hoc Set, perhaps, using one of these libs would be a wise choice.
I'm writing a parser to parse CSS.
I started by modifying the CSS reference grammar, to use whichever grammar and lexer syntax are supported by the 3rd-party parser generator tool which I'm using.
I think that I've finished coding the grammar: the parser-generator is able now to generate state transition tables for/from my grammar.
The result (the output from the parser-generator) is approximately 116 "rules", which correspond to 116 cases in a switch statement. Examples of these rules/switch statements are:
Stylesheet begins with specifying a charset
Stylesheet begins without specifying a charset:
Stylesheet is empty
Stylesheet begins with whitespace
...etc...
The parser-generator has done all it can for me, and now I'm begining to write (by hand) the various cases of the switch statements, which will build what I think people call an 'abstract syntax tree'.
My question is about how to test this. I think that what I want is a set of CSS files which exercise the various combination and possibilities: e.g. one CSS file which specifies a charset; another file which doesn't specify a charset; etc.
Is there general a way to auto-generate this set of input data, for an arbitrary grammar or set of rules?
Alternatively, is there a set of specifically CSS files, whose purpose is to cover the combination and possibilities allowed by the standard CSS grammar?
Feel free to comment too if I'm going about this all wrong.
At the moment I don't need:
Files to test handling of illegal input (i.e. of files which don't conform to the grammar)
Testing of how various browsers render based on their parsing of CSS
Microsoft made a set of many thousands of CSS tests for IE8 compliance with the CSS spec.
http://samples.msdn.microsoft.com/ietestcenter/css.htm
While they are focused on testing browser compliance, possibly you could adapt them.
There are also the older W3C test suites, which are not as complete, but might serve your purpose:
http://www.w3.org/Style/CSS/Test/
A context free grammar implicitly proposes an infinite set of (parse) trees. Each proposed tree has a set of leaves which make a concrete sentence in the language accepted by that grammar. By exploring the the set of proposed trees (e.g, by expanding each nonterminal according to it possible alternatives), you can generate any arbitrary instance of the language. You can generate a set of tests by walking the tree proposals and making random choices. A more focused approach would be to use iterative deepening search to generate sentences ordered by size. With any interesting grammer, you're likely to get a huge number of instances, but hey, that's what automated testing is for.
What I wouldn't do is generate such sentences from your production grammar, because the sentences you generate will be, by definition, the ones it accepts :-{ What you should do is construct your sentence generator using the reference grammar, to exploit the fact that you what it accepts and what you've implemented might be different.
4 years late for OP but SimonSapin/css-parsing-tests seems like a decent test suite for parsers.
The scope of my question is solely ASP.NET, as the answer may be different for Java and any other C based language.
How much overhead is involved when using the keyword "this" within a class to dereference a property? It seems that I've seen certain sources try to discourage the use of "this" for dereferencing, but generaly I've just ignored them until now.
I think it is just a style issue. As stated in the answer to this question, the compiler injects 'this' into implicit uses of this. I would use it for clarity.
StyleCop recommended using this for all instance field reference.
And when compared to access the said field through a property, shouldn't it actually be faster (albeit unnoticable) by bypassing abstraction?
No overhead.