In Terraform I can use:
name = "${var.names["apple"])"
which looks up the string "apple" in var.names.
However, this syntax would break in most programming languages as it would try and parse "${var.names[" then apple then "])".
I've looked up documentation on this but failed to find anything. Are there any details?
I've read:
https://www.terraform.io/docs/configuration/syntax.html
and
https://www.terraform.io/docs/configuration/interpolation.html
The last link briefly gives an example
template = "${file("templates/web_init.tpl")}"
but doesn't explain.
Upgrade guide to v0.7 explicitly introduces nested quoting context. Apparently this had been allowed since one of the earlier versions, but I could not pinpoint which one exactly.
I was wondering about some best practices regarding extraction of selectors to constants. As a general rule, it is usually recommended to extract magic numbers and string literals to constants so they can be reused, but I am not sure if this is really a good approach when dealing with selectors in Capybara.
At the moment, I have a file called "selectors.rb" which contains the selectors that I use. Here is part of it:
SELECTORS = {
checkout: {
checkbox_agreement: 'input#agreement-1',
input_billing_city: 'input#billing\:city',
input_billing_company: 'input#billing\:company',
input_billing_country: 'input#billing\:country_id',
input_billing_firstname: 'input#billing\:firstname',
input_billing_lastname: 'input#billing\:lastname',
input_billing_postcode: 'input#billing\:postcode',
input_billing_region: 'input#billing\:region_id',
input_billing_street1: 'input#billing\:street1',
....
}
In theory, I put my selectors in this file, and then I could do something like this:
find(SELECTORS[:checkout][:input_billing_city]).click
There are several problems with this:
If I want to know the selector that is used, I have to look it up
If I change the name in selectors.rb, I could forget to change it somewhere else in the file which will result in find(nil).click
With the example above, I can't use this selector with fill_in(SELECTORS[:checkout][:input_billing_city]), because it requires an ID, name or label
There are probably a few more problems with that, so I am considering to get rid of the constants. Has anyone been in a similar spot? What is a good way to deal with this situation?
Someone mentioned the SitePrism gem to me: https://github.com/natritmeyer/site_prism
A Page Object Model DSL for Capybara
SitePrism gives you a simple, clean and semantic DSL for describing
your site using the Page Object Model pattern, for use with Capybara
in automated acceptance testing.
It is very helpful in that regard and I have adjusted my code accordingly.
This is PascalCase: SomeSymbol
This is camelCase: someSymbol
This is snake_case: some_symbol
So my questions is whether there is a widely accepted name for this: some-symbol? It's commonly used in url's.
There isn't really a standard name for this case convention, and there is disagreement over what it should be called.
That said, as of 2019, there is a strong case to be made that kebab-case is winning:
https://trends.google.com/trends/explore?date=all&q=kebab-case,spinal-case,lisp-case,dash-case,caterpillar-case
spinal-case is a distant second, and no other terms have any traction at all.
Additionally, kebab-case has entered the lexicon of several javascript code libraries, e.g.:
https://lodash.com/docs/#kebabCase
https://www.npmjs.com/package/kebab-case
https://v2.vuejs.org/v2/guide/components-props.html#Prop-Casing-camelCase-vs-kebab-case
However, there are still other terms that people use. Lisp has used this convention for decades as described in this Wikipedia entry, so some people have described it as lisp-case. Some other forms I've seen include caterpillar-case, dash-case, and hyphen-case, but none of these is standard.
So the answer to your question is: No, there isn't a single widely-accepted name for this case convention analogous to snake_case or camelCase, which are widely-accepted.
It's referred to as kebab-case. See lodash docs.
It's also sometimes known as caterpillar-case
This is the most famous case and It has many names
kebab-case: It's the name most adopted by official software
caterpillar-case
dash-case
hyphen-case or hyphenated-case
lisp-case
spinal-case
css-case
slug-case
friendly-url-case
As the character (-) is referred to as "hyphen" or "dash", it seems more natural to name this "dash-case", or "hyphen-case" (less frequently used).
As mentioned in Wikipedia, "kebab-case" is also used. Apparently (see answer) this is because the character would look like a skewer... It needs some imagination though.
Used in lodash lib for example.
Recently, "dash-case" was used by
Angular (https://angular.io/guide/glossary#case-types)
NPM modules
https://www.npmjs.com/package/case-dash (removed ?)
https://www.npmjs.com/package/dasherize
Adding the correct link here Kebab Case
which is All lowercase with - separating words.
I've always called it, and heard it be called, 'dashcase.'
There is no standardized name.
Libraries like jquery and lodash refer it as kebab-case. So does Vuejs javascript framework. However, I am not sure whether it's safe to declare that it's referred as kebab-case in javascript world.
I've always known it as kebab-case.
On a funny note, I've heard people call it a SCREAM-KEBAB when all the letters are capitalized.
Kebab Case Warning
I've always liked kebab-case as it seems the most readable when you need whitespace. However, some programs interpret the dash as a minus sign, and it can cause problems as what you think is a name turns into a subtraction operation.
first-second // first minus second?
ten-2 // ten minus two?
Also, some frameworks parse dashes in kebab cased property. For example, GitHub Pages uses Jekyll, and Jekyll parses any dashes it finds in an md file. For example, a file named 2020-1-2-homepage.md on GitHub Pages gets put into a folder structured as \2020\1\2\homepage.html when the site is compiled.
Snake_case vs kebab-case
A safer alternative to kebab-case is snake_case, or SCREAMING_SNAKE_CASE, as underscores cause less confusion when compared to a minus sign.
I'd simply say that it was hyphenated.
Worth to mention from abolish:
https://github.com/tpope/vim-abolish/blob/master/doc/abolish.txt#L152
dash-case or kebab-case
In Salesforce, It is referred as kebab-case. See below
https://developer.salesforce.com/docs/component-library/documentation/lwc/lwc.js_props_names
Here is a more recent discombobulation. Documentation everywhere in angular JS and Pluralsight courses and books on angular, all refer to kebab-case as snake-case, not differentiating between the two.
Its too bad caterpillar-case did not stick because snake_case and caterpillar-case are easily remembered and actually look like what they represent (if you have a good imagination).
My ECMAScript proposal for String.prototype.toKebabCase.
String.prototype.toKebabCase = function () {
return this.valueOf().replace(/-/g, ' ').split('')
.reduce((str, char) => char.toUpperCase() === char ?
`${str} ${char}` :
`${str}${char}`, ''
).replace(/ * /g, ' ').trim().replace(/ /g, '-').toLowerCase();
}
This casing can also be called a "slug", and the process of turning a phrase into it "slugify".
https://hexdocs.pm/slugify/Slug.html
There is a common problem in languages that assume variable declarations are local. How do you get at variables in enclosing scopes.
Is there a way in Opa?
For example:
start() =
name = Random.string(5)
set_name(new_name) =
old_name = name
name = new_name
log("User {old_name} changed name to {new_name}")
This doesn't work. We get a warning that name is unused in set_name, and the value of name in start is never changed.
In a language like Lua, Javascript or Scheme, there is explicit marking of locals, so variables not marked in that way can be found in the scope stack. In Python there is no such marking, and so this would be impossible. In Python you can get at global (toplevel) variables, and I've found the #toplevel directive in Opa too. But I'm interested in intermediate points in the scope chain.
There are workarounds, of course, by using records, but is there a direct route?
One solution is to use Reference module :
Reference.create, Reference.get, Reference.set
http://opalang.org/resources/doc/index.html#stdlib.core.reference.opa.html/!/value_stdlib.core.Reference
Reference module mentioned in Fred's answer is indeed one solution to this and it's closest to what you are asking for.
But it's also good to know that when programming the "right way" most of the state in your Opa program will be captured in Sessions, with a change to the session's state triggered by a message send to it.
The rules for resolving SIDs in COLLADA, and COLLADA FX SIDs in particular, are not very clear. With regard to COLLADA FX SIDs in particular, how do I know at which element to start the search for a particular SID? Consider, for example, the "texture" atttibute of a <texture> element:
<effect id="Scene_Material_fx">
<profile_COMMON>
<newparam sid="acorn_png_surface">
<surface type="2D">
<init_from>acorn_png_img</init_from>
</surface>
</newparam>
<newparam sid="acorn_png_sampler">
<sampler2D>
<source>acorn_png_surface</source>
</sampler2D>
</newparam>
<technique sid="default">
<phong>
...
<diffuse>
<texture texture="acorn_png_sampler" texcoord="diffuse_TEXCOORD"></texture>
</diffuse>
...
</phong>
</technique>
</profile_COMMON>
</effect>
I can find the SID referenced by <texture> if I start the search at <profile_COMMON>, which is the great-great-grandparent of the <texture> element that contains the reference, but I can also find it if I start searching from <effect>. How, then, is the starting element determined? Is it defined somewhere in the spec?
Does the spec provide a limit to how close to the document root an sid referenced by a particular <texture> element may be found? In the above example, could it possibly appear outside of <profile_COMMON>, such as inside its <effect> parent? Which is the "rootmost" element at which I am guaranteed to find the referenced sid by drilling down from that element?
Update: I have also posted this question in the COLLADA forums, so far with no response. I've decided that, for the time being, I shall simply assume the SID referenced by a <texture>'s "texture" attribute will always be found under <profile_COMMON>. If that's wrong it means my importer may fail on valid input, but the COLLADA community itself has offered no feedback on this so there's nothing I can do.
I can feel your pain ;-). Collada specs are really hard to understand.
As you can have params declared in <effect> scope (not only inside <profile> : Chapter 7 About parameters) you should look there too.
But. Judging from my experience exporters tends to have local params (under <profile>) so your way will work too.
This is an old question, but I believe the answer is that SID's are 'scoped id's' at the level of the parent ID. So you technically begin searching just under the element, and all sids are unique under that block.
That was always my understanding, anyway...