DEV Community: Max Cerrina

Packages 101

Max Cerrina — Wed, 20 Feb 2019 18:36:33 +0000

Many web development projects use different packages. You will often see people talk about packages -- installing them, which ones they like, which ones they don't, how their size compares to others', whether a certain package was useful, etc. Packages are closely related to dependencies -- things your code needs in order to work.

Dependency management can be very complex; we won't go over things like versioning, etc. Different people and teams use different package managers; here, we'll just be using npm, which is very common.

We won't make a real project, just go over the package management portion of it. If you want to try the commands yourself, you will need:

node and npm
a terminal to run the commands in

So what are packages, anyway?

A package is code you want to use in your own project that comes from somewhere else. They can be used either just for the developers -- such as a package that lets you write and run tests for your code -- or in the project itself, such as a library of functions to make it easier to talk to websockets, or a package that gives you pre-made CSS classes to use in your code. Using a package instead of writing it yourself can save you a lot of time, and also make things easier. For example, maybe you don't know (or care to!) how the websocket protocol works, you just want a tool that lets you use it a chat app. Frequently, packages are talked about as dependencies: things your code needs in order to function correctly.

A package manager is a tool you can use to handle packages for you: usually that means you use it to add (install) new packages, remove (uninstall) them, find new ones, etc. npm is a package manager. You could just find the code somewhere online and put it in its own script file in your source folder instead of as a package -- but if that code changes, or gets updated, you have to go find it again, get the new code, put it in yourself ... assuming you even know the code you're using was updated at all.

A package manager like npm also helps you manage which version you should install. It has a registry of the packages, where it stores the packages, their versions, etc. npm's registry is at npmjs.com. Usually it will also take care of installing any dependencies of the packages you've installed, so that they will work.

Quick syntax notes

<package_name>: the name of a single package. The angle brackets (< and >) are a common way of showing that you should replace that whole term (<package_name>) with what you want it to be. Often, when you see angle brackets in documentation, it indicates that the value that goes there is required. You do NOT use the < and > when you run the commands. Examples:
- npm view <package_name> => npm view react to view information about a package named react
- npm search <package_name> => npm search cool_new_package to look for a package named cool_new_package
[list_of_packages...]: a list of package names. The square brackets ([ and ] are a common way of showing that something should be a list with a varying number of things inside it. It could have one item or many items. When you see something with square brackets in documentation, that usually means it's optional. You do NOT use the [ and ] when you run the commands. For example, npm install [list_of_packages...] could be:
- npm install jest chalk request: install three packages -- one named jest, one named chalk, and one named request
- npm install react: install one package named react
- npm install: install all of the packages listed in the package.json file
an option is something like --save-dev or --depth: it's used to give the command itself more information, like arguments to a function. Often they have a short form and a long form; e.g., the option for saving something in devDependencies on an npm command is written as --save-dev or -D. Usually the long version has two dashes (--save-dev), whereas the short version usually as just one (-D). We'll use the long versions here (I do when I run them myself, honestly!) because they are easier to understand.

Getting started

Before we can add packages to a project, we need a project to add them to!

Often, you'll be working on a project that already exists, so you won't need to do this, but it's good to know how. It's a great way to create a sandbox to try things in without worrying that you might do something wrong.

npm uses a file called package.json for getting information about your project, like what dependencies it has. While it contains a lot of other important information, today we'll just focus on what it does for packages (explained more when we address how to add them).

You can make a new project by creating a new folder, and from within that folder, running one of two commands, both of which result in npm making a package.json file for you.

npm init: starts an interactive app that asks you some questions and then creates a package.json file for you
npm --yes init: creates a default package.json file for you, and doesn't make you answer any questions or pick anything (usually this is what I do to get started, it's faster)

Don't worry if you change your mind about an option you picked, or if you decide you want to add something later; package.json is just a file, and you can edit it in a text editor afterwards if you like.

If you are using git in your project, make sure you have node_modules added to your .gitignore file. You can do that by adding it to the file in a text editor, or by running echo 'node_modules' >> .gitignore from the command line.

Finding packages

The easiest way to find a package is probably to look at the npm registry's site -- you can search for packages, see how many people have used it, etc., get an idea of how its documentation is, etc. There are a lot of packages available: for whatever you're looking for, there is almost certainly an existing package, if not many, that will do what you need. If you try one and you don't like it, or it's too hard to use, try looking for another!

When you're looking at different packages, it can be helpful to look at the package's Github; this can give you an idea of how active it is, how many issues there are, etc. A package that hasn't been updated in a while isn't necessarily bad or out-of-date -- it may not have needed updates. Similarly, a package with a lot of issues on Github may have that many issues because it has a lot of users; it doesn't mean the package is bad or poorly maintained.

There are also commands you can run to see a lot of the same information from the command-line
(remember, don't use the < and > when you run these with real package names!):

npm search <package_name>: look for all packages in the npm registry whose name matches <package_name>
npm view <package_name>: view detailed information about a package, such as its versions, keyswords, description, its own dependencies, etc.

Adding new packages to a project

When you install a package, npm gets the package and puts it into your node_modules folder, as well as anything else that package itself needs. npm uses your package.json file to know what packages (and which versions) to install, as well as a lot of other things.

There are two main kinds of dependencies in your package.json folder: dependencies and devDependencies. (There are also other kinds, but we won't worry about them today.)

dependencies are packages your project needs in order to run. If you are using a package like moment to handle math involving dates in your project, that would be a package you should have in dependencies: it's required for your project to work.
devDependencies are packages you want but that your code itself doesn't need to run when it's finished. A tool like TypeScript or Babel that compiles your code is a good example of a common devDependencies package: you need it while you're working on the code, but your project itself doesn't need it to run. Something like a testing tool, or a linter, are also good examples of what would belong in devDependencies.

To add a new package, you use the npm install command. npm will also add the package information to your package.json file as a dependency automatically.

(Remember, don't use the [ and ] when you run these with real package names!)

npm install --dry-run [list_of_packages...]: do everything as if you were going to install these packages, short of actually installing them.
npm install --save-dev [list_of_packages...]: install these packages and add them to our package.json as devDependencies
npm install --save-prod [list_of_packages...]: install these packages and add them to our package.json as dependencies
npm install --global [list_of_packages...]: install these packages globally -- if you do this from a project folder, these packages will not be added to your package.json files in the project. A good example of when you might want to use this is for a tool like create-react-app that helps you start a new project: because you want it to make the project, you don't want to install it locally inside the project.

Dealing with existing packages

If you've just cloned an existing project, the first thing you should do is run npm install.

Because node_modules folders get very large very quickly, they are almost always excluded from version control like git. That means that when you clone down a project, any packages you need aren't there yet, and the code won't work.

Once you have packages in a project, you will sometimes need to remove or update them; it's good to also just peruse things every so often, make sure you don't have unnecessary packages left lying around, etc.

npm uninstall [list_of_packages...]: remove the packages listed (can be just one package); this will remove them from your package.json file as well as from your node_modules directory.
npm list --depth 0: view list of all packages installed at the top level; to view all packages and all their dependencies, you can do npm list --depth 1000
npm la --depth 0: view list of all packages installed, along with their descriptions at the top level
npm outdated: view packages which are behind the desired version

Remember that using tools is a skill, and it takes practice to get good at it; it might feel weird or seem silly, but it can be helpful to make and delete a dozen fake projects just to practice setting them up, wrangling packages, etc.

There are a many more commands, and a lot of different ways to use them; you can read more about them in the documentation for the npm, or by running npm help <command> to get information about that specific command.

Minimal (yes, truly) TypeScript setup

Max Cerrina — Sat, 05 Jan 2019 21:55:13 +0000

One of the most frustrating things ever is wanting to try something out and having to install a million things and learn 3.14 new tools just to get something runnable in your browser.

I wrote up a minimal server and repository for a project that compiles your TypeScript down for use in a browser environment, so that people can try TypeScript if they want, without worrying about things like loaders, webpack, etc.

aleph-naught2tog / ts_without_dependencies

Dependency-free skeleton for a web site with Typescript

Dependency-free Typescript setup

This is a truly minimal, dependency-free setup that will provide the skeleton for you to:

write your code in Typescript
compile it for browser use
use that compiled code in a browser environment

That's it. This server won't do anything fancy: it won't reload for you, it won't minify or uglify anything.

It will serve files for you, and that's it. You can ignore the server entirely if you want; or, if you think writing your own server sounds neat, the second half of the README is worth checking out.

There's no magic here. No Webpack, no loaders, no routing libraries necessary, etc. (If you don't know what those are, don't worry -- the point of this repository is so you don't have to.) There's nothing wrong with using those tools, but they add complexity, and they can extremely frustrating to use when all you really want…

View on GitHub

Its only dependency is TypeScript itself. Literally. (Well, okay, Node too, but TypeScript itself uses Node, so I think that's permissible.)

If all you want is to try a basic website with TypeScript, this is perfect for that.

If you want to try writing your own server, please use this as a base if you want -- I included notes in the server files, let me know if anything is unclear! -- but if you want nothing to do with the server, you shouldn't need to mess with its code.

new Array(1) => [empty title x 1]

Max Cerrina — Fri, 04 Jan 2019 18:52:46 +0000

Imagine it's been a rough week.

Finally, it's time to refill our weekly chocolate supply. As usual, we're using JavaScript to fill our chocolate supply.

In pseudocode, "a box of 21 of the same kind of chocolate" would be something like:

Get a box.

Make sure the box has enough slots for 21 chocolates.

As long as there are still empty slots:

Get a chocolate from the giant bag of chocolates.

Put one chocolate into the slot you're looking at.

Move on to the next slot.

Pretty reasonable, right? Let's give it a shot!

(Note: all snippets should be runnable as-is in a repl or console as desired, just by copy-pasting if you like.)

Attempt 1: `.map`

For a first swing, maybe we'd try map:

let chocolate = {
    kind: 'dark',
    filling: 'raspberry ganache'
};

// Prep our box and make sure it has 21 slots
let weeklyChocolateSupplyBox = new Array(21);

// Put one chocolate into every slot
weeklyChocolateSupplyBox.map(_emptySlot => chocolate);

(If you're wondering about the underscore (i.e., _emptySlot), that means the variable is either unimportant or unused. Some languages enforce that as a rule, like Elixir; here, it's purely convention.)

So far, so good: we make an array with 21 slots, we loop over it with map, and put a chocolate in at each slot.

We actually put the exact same chocolate in each slot, which would be less than ideal in the real world — any changes to any one chocolate would effect EVERY chocolate, as they are all this way the same chocolate.

(╯°□°）╯︵ [Ɛ x ʎʇdɯǝ]

Maybe not too surprisingly, it doesn't work. Instead of an array containing 21 identical chocolates, if you run that snippet in a console, you'll get something like: [empty × 21].

Less than ideal, to say the least.

Attempt 2: `for (let index ... )`

While I love using the various array methods when I can — e.g., forEach, filter, map, etc., I've found that since I learned C-style for loops first, I often refer back to them when things aren't working. Similarly, as a sanity check, I often log out something before and after the loop, so I can make sure nothing truly whacky is going on like being in the wrong file, etc.

At the end of the day, a loop is a loop, use what is clearest to you and others.

So, we try again!

// same as before
chocolate = {
    kind: 'dark',
    filling: 'raspberry ganache'
};

// assign the variable a whole new array to reset.
weeklyChocolateSupplyBox = new Array(21);

console.log('before loop');
for (let index = 0; index < weeklyChocolateSupplyBox.length; index += 1) {
    console.log('loop number %d', index);
    weeklyChocolateSupplyBox[index] = chocolate;
}

console.log(weeklyChocolateSupplyBox);
console.log('after loop');

This time, we succeed. We have a box with 21 chocolates in it, as desired! Awesome.

Attempt 3: `for ... of`

Say that I didn't use an old-school for loop: say I had gone ahead with a for ... of loop — after all, I want to loop over this array and put things into it, right? This way, too, I can eliminate needing to increment the index myself, and not worry about if I forgot a condition or something. Great!

So let's write the code, and use a for ... of loop instead. We start off the same as before, and sketch out the skeleton of our for loop.

chocolate = {
    kind: 'dark',
    filling: 'raspberry ganache'
};

// assign the variable a whole new array to reset.
weeklyChocolateSupplyBox = new Array(21);

console.log('before loop');
for (let emptySlot of weeklyChocolateSupplyBox) {
    console.log('emptySlot', emptySlot);
    // Put a chocolate into our emptySlot
}
console.log('after loop');

...but what goes inside the loop? We have an emptySlot — but no way to add a chocolate to it. If we ran this now, we'd just see emptySlot undefined logged out 21 times. Not helpful.

Attempt 4: `for ... in`

In JavaScript, everything is an object. Arrays are too — in particular, are an object created by the Array constructor. By definition, they have a length property, and numeric, ordered keys.

There's another kind of for loop we haven't tried: for ... in, which loops over the properties of an object. For something like an object literal, it loops over the property names; for an array, it loops over the indices. A little weird, but if you think about it, that seems sort of reasonable — we can use both a string key and an array index to set the value, and then later access that value by the key, right?

const dog = { name: 'Simon', age: 13, weight: 50 };
const someNumbers = [3, 1, 4];
for (let key in dog) {
    console.log('dog key', key); // 'name', then 'age', then 'weight'
    console.log('dog value', dog[key]); // 'Simon', then 13, then 50
}

for (let key in someNumbers) {
    console.log('someNumbers key', key); // '0', then '1', then '2'
    console.log('someNumbers value', someNumbers[key]); // 3, then 1, then 4
}

Okay, cool, nothing too interesting there, except for maybe being able to do that with arrays as well.

So, let's try the chocolate experiment again. The normal for loop worked — let's try the same thing but with a for ... in loop, and we can use the index to add it to the array like before.

chocolate = {
    kind: 'dark',
    filling: 'raspberry ganache'
};

// assign the variable a whole new array to reset.
weeklyChocolateSupplyBox = new Array(21);

console.log('before loop');
for (let emptySlotIndex in weeklyChocolateSupplyBox) {
    console.log('emptySlotIndex', emptySlotIndex);
    weeklyChocolateSupplyBox[emptySlotIndex] = chocolate;
}
console.log('after loop');

This time, we see before loop and after loop, and ... literally nothing else.

What's the difference?

So, we tried a number of things:

map: failed -- did nothing
for ... of loop: failed -- no way to add a chocolate
for ... in loop: failed -- never even looped!
basic for loop: worked!

None of this answers the question, though: why does a for loop work and the other options fail, with for ... in never looping?

The answer lies in the specification of JavaScript itself.

The Array constructor does create an Array object and set its length to be the (single, numeric) value given¹.

What it does not do, though, is set the indices (which are just keys, remember, which happen to be numbers) on the array object.

// This is about what happens:
const newArray = {
    length: 2
};

// NOT this:
const badNewArray = {
    length: 2,
    '0': undefined,
    '1': undefined
};

If you've ever tried to remove something from an object — truly get rid of it, not just give it an undefined value, but remove the property entirely — you know that chocolate['filling'] = undefined won't cut it. The property will still be there, just with undefined as its value.

To remove a property, you have to delete it: delete chocolate['filling'];. After that, if you inspect the object, there will be no key called filling present. If we looked at its keys, we would not see filling listed.

So, what happens if you delete an index from an array?

const someOtherArray = ['value at 0', 'value at 1', 'value at 2'];

console.log(someOtherArray); // ["value at 0", "value at 1", "value at 2"]
console.log(someOtherArray.length); // => 3

delete someOtherArray[1];

console.log(someOtherArray.length); // => still 3
console.log(someOtherArray);
// Chrome:  ["value at 0", empty, "value at 2"]
// Firefox: ["value at 0", <1 empty slot>, "value at 2"]
// Safari:  ["value at 0", 2: "value at 2"]

Each browser shows you the same thing, just differently: an array with length three and only two things in it, at 0 and 2. There's nothing at index 1 anymore — because there is no index 1. Each array still has a length of 3.

This explains why for ... in failed so badly: the for ... in loop works over the keys of an object: there were no keys (indices) for it to enumerate over. Similarly, if we had looped above, both before and after deleting the index, we would have gone into the loop 3 times before deleting the index, and twice after its deletion.

A not-so-well-known symbol

Here's another clue: [...new Array(3)] does what we had probably originally expected — and gives us [undefined, undefined, undefined].

The answer is iterators; specifically, the value of the Symbol.iterator on an object. (Symbols are a JavaScript primitive whose value is unique, and are often used as identifiers — much like atoms in other languages.)

If an object has a Symbol.iterator, that object is iterABLE: it has an iterATOR, an object that adheres to the iterator protocol. Iterators are very neat and very powerful — they're the guts behind async, await, generators, promises, the spread operator, for ... of, etc; they allow for entering and exiting different execution contexts asynchronously.

For our purposes, though, it's enough to know that an iterator essentially keeps track of your place in a loop. Many JavaScript objects have a default iterator — arrays, as well as anything else that you can spread (use ... as above).

In particular, the default iterator specification² says something like:

Start with index = 0.

As long as index is less than array.length:

Yield the value of array[index]

Increment the index, index += 1

Keep going

Lots of other array methods use similar logic — e.g., toString uses join, which has a similar algorithm.

What do you get when you access a property that isn't on an object? In some languages, it wouldn't compile at all; in JavaScript, however, you don't get an error, you just get undefined — which, of course, can also be the value if the key is there.

const withKeyAndUndefined = { apples: undefined, pears: 3 };
const withKeyAndValue = { apples: 12, pears: 99 };
const withoutKey = { pears: 74 };

console.log(withKeyAndUndefined['apples']); // => undefined
console.log(withKeyAndValue['apples']);     // => 12;
console.log(withoutKey['apples']);          // => undefined

As for map failing as well?

Well... The specification³ for map (and forEach and other similar methods) spells out that the callback given is only executed for those values "which are not missing" — that is, non-empty slots or where the indices are defined (so, nowhere right after construction).

const yetAnotherArray = new Array(5);

yetAnotherArray.map(
    value => {
        throw new Error('never gonna happen');
    }
).fill(
    null // now we put something in every spot
).map(value => {
    console.log('now, this will show "null": ', value);
    return value;
});

Meanwhile, our basic for-loop worked right off the bat: because we were creating those indices by setting a value under that key, the same way I can do const dog = {name: 'Simon'}; dog.favoriteFood = 'peanut butter'; without favoriteFood ever having been defined as being on the original object.

const array = new Array(5);

for (let index = 0; index < array.length; index += 1) {
    // does 'index' exist? Yes! It's its own variable, after all
    console.log('index', index);
    console.log(`before: ${index} in array?`, index in array);
    array[index] = 'whee';
    console.log(`after: ${index} in array?`, index in array);
}

There is, conveniently, a method to fill an array with any value. We can use that here, too.

For a simple case, we can just do new Array(5).fill(chocolate); for anything more complex, though, we need first to fill the array with something — anything, even null or undefined.

weeklyChocolateSupplyBox = new Array(21).fill(chocolate);
console.log(weeklyChocolateSupplyBox);

const rangeFrom_1_to_10 = new Array(10).fill(null).map((_null,index) => index + 1);

console.log(rangeFrom_1_to_10);

Remember, though, that what we actually end up with here is 21 references to the same chocolate — if we melt one chocolate, they all melt, as what we really did was put the same identical chocolate into every slot through some truly spectacular quantum confectionary. (Chocolate, however, seemed much more enjoyable than an array of strings or numbers.)

Possessive Quantifiers -- or "Hey, that's MY match!"

Max Cerrina — Sat, 01 Sep 2018 01:06:03 +0000

While messing around with parsing the Dev.To survey, I found myself with a particularly clear-cut example of a possessive quantifier in a regular expression -- one of the rare(r) pockets of regex syntax, and one I've never really gotten, so I was excited to finally see an example of it "in the wild" that made it all click for me.

First, an extremely whirlwind regular expression breakdown: a regular expression is a string written with a special syntax that is used to describe what a string it tests can have.

A good example of this is a regex for an rgb color in CSS: we could write something that checks a given string against every single possible rgb color -- so rgb(0,0,0), rgb(0,0,1), all the way up to rgb(255,255,255) -- but boy, wouldn't it be easier if we could just describe what one looks like?

We know it starts with rgb, then some parentheses, and that inside those parentheses will be three numbers. A regular expression lets you do just that -- you get something you can test strings against, to see if they match. Your regular expression for an rgb color would describe just that: an rgb color starts with rgb, then opens the parentheses, and that inside those parentheses will be three numbers, and then we close the parenthesis. If we translated that literally to regular expressions, it wouldn't be a perfect regex for an RGB color, but it would be a good start -- it would definitely reject things with no numbers, with no parentheses, that didn't start with rgb, etc.

Quick notes

Regexes are signified by delimiters, often two /s: so /apple/ is a regex whose characters are the same as the word "apple", but apple isn't a regular expression, it's just a string.
When I talk about a regex matching below, I am going to use that to mean the whole string being tested: e.g., /a/ matches a and not apple; /\d+/ matches 0 or 92819281, but does not match ag3. Finding a match refers to finding SOME string portion which it matches inside a bigger string -- /apple/ matches "apple", and finds a match in "oranges and apples".
To try these, I suggest using Regex101, because it has the PHP option enabled by default, and it also has syntax highlighting, a debugger, etc. JavaScript WILL NOT WORK for the main examples below.

Quantifiers

In regexes, quantifiers lets you say how many of something you want.

The most common ones are: ?, *, +, and the literals, which are one number in curly braces, or two comma-separated numbers in curly braces. We're just going to talk about the first three today.

? means the unit can show up 0 or 1 time: the unit is optional, but if it is there, it can only be there once. /apples?/ matches both apple and apples, but not applesssss.
* means the unit can how up 0 times (not at all), or any other number of times: 0 is fine, 1 is fine, 15000 is fine. /apples*/
+ means a unit is required to be present at least once, but it's OK if it shows up more than once, too.

Most frequently, you will see * and + with a wildcard like . (which can match anything that is not a linebreak), or classes (a group of characters that are allowed in one spot -- /[a-z]/ means all characters from a to z, /[xyz]/ is only those three letters, etc. Some common character classes have a shorthand notation -- for example, /\d/ is the same as /[0-9]/: any character from the character 0 to the character 9; /\s/ usually[1] matches at least spaces or tabs.

/[a-z]\d?/ means we want one letter, and maybe a number after -- a and a2 would match, but a331 would fail.
/[a-z]\d*/ means any or no numbers are fine -- a and a12345 would both match.
/[a-z]\d+/ means 1 to many numbers are fine -- a12 would match, but a would fail.

It makes sense that we see these most with wildcards or classes -- if we are matching more than one of something, odds are high that we are talking about a broader category than one character. /[a-z]+/ could describe just about most words -- "at least one, and possibly many, letters". Note that they don't have to be the SAME letter -- /[a-z]+/ can match "aaaaaaah", but could also match "kslqm".

Possessive quantifiers

Some languages let you combine them to make a ~~super ultra fancy hardcore~~ other quantifiers, like to make a possessive quantifier or a lazy quantifier.

A possessive quantifier looks like /\d*+/ or /\d++/ -- it means "when you match this, refuse to give any characters back to match."

Perfectly clear, right? Yeah... no.

OK, remember how I said I had an example? So let's do this. I had wanted to start processing the survey results, and wanted to start off by stripping out a bunch of stuff from the data itself and getting it into a format that I wanted, like a bunch of insert statements or something.

So, for the headers, I wanted to ditch the numbers, specifically.

1. Which is your primary browser for development    2. Which of the following technologies have you made use of?    2. Which of the following technologies have you made use of?    3. How old

While I was at it, I knew I would want to also wanted to ditch the whitespace and punctuation, so I started tinkering.

Like with a lot of other things, I try and start with something that I know will work, which for a regex is usually just making sure I can start where I want and stop where I want. I could see the questions were numbered, and that the numbers had periods after them, then some whitespace, then after the whole question there was more whitespace before the next number. I used "not a digit" for most of the question, because it's faster and more accurate[2] for what I wanted (at least here -- I'm making a pretty massive assumption, that none of the questions contain numbers).

Here is the regex I ended up with:

# link: https://regex101.com/r/nGrjKq/3/
/(?x)
\d+     # at least one digit
\.      # a period
\s      # a space
[^\d]+  # something that isn't a digit -- at least one, and maybe more than one
\s+     # a space -- at least one, and maybe more than one
/

Now, that works great.

So why would I try a possessive quantifier?

I could be clever and say it's because I know they're usually faster (which is true) -- but honestly, it's because I hit the + twice on accident and it failed, and I was confused.

Confused about what? Well, the regex below will fail on the same string we were testing above, whereas the first one will work. There's a second + on line 5 -- in the first version, it is [^\d]+, below, it is [^\d]++. (Oofda.)

# failing version: https://regex101.com/r/zM15hD/1/ 
/(?x)
\d+     # at least one digit
\.      # a period
\s      # a space
[^\d]++ # something that isn't a digit -- at least one, and maybe more than one
\s+     # a space -- at least one, and maybe more than one
/

With the above version, we fail completely: no matches are found. Because the possessive quantifier won't give any back -- + is greedy by default, so it keeps on chomping until it fails. When it fails, the regex engine backtracks, if it can, to see if it can find a match by doing so -- to backtrack, it gives up what it has consumed so far, in hopes of making a match.

Uh, what?

"Don't give any back"

When a regular expression engine tries to match, it goes as long as what it finds is accepted by its current state -- which is a fancy way of saying "it goes until it can't any more, because it's out of charaters or fails completely." If you play around on Regex101, you'll see pretty fast that when you write one that doesn't match, the step count is often way higher than when it does match -- because the engine will keep going through the string, hoping to find a location it can match from. If it were trying to find the phrase "Dev.To" in Hamlet, it would have a tooooon of steps -- because it would search everything, hoping to find it starting at the next character since it hadn't yet.

As it goes, it consumes things. Once something has been consumed, it's not able to be used again if things are going well -- if it fails, though, the engine will start to backtrack to try and find a match. (This is often one of the biggest issues in terms of regex efficiency, by the way.)

In our example -- we want a bunch of stuff that isn't a digit, then at least one space. When the regex engine walks down the string, it gobbles up eeeeeverything that isn't a digit until it finds one -- in our test string, that would be the 2. Now, though, it needs a space to match -- so it backtracks, since "not a digit" could certainly be a space character, and sure enough, it finds some, and uses those to match the \s+, and matches fine.

When we use the possessive modifier -- we don't allow it to backtrack. So the same thing happens: it walks, it gobbles up everything that isn't a digit and it hits that 2, but needs a space to match. Since we used the ++, it can't backtrack, so it fails to match -- it consumed those spaces already.

Moral of the story

Sharing is caring! (Er, probably not the right one here, huh.)

What I ended up with a little tweaking was this regex -- similar, but a little more specific, and only a few steps more at least for this test. I ended up ditching the spaces before the next digit -- that is easily removed with trim, decided to keep the possessive quantifier because I rarely use them, and I got to use a lookahead, which I just really enjoy for no good reason.

# link: https://regex101.com/r/7lFnEs/3
(?x) 
\d+      # at least one digit
\.       # a period
\s       # a space
[^\d]++  # not a digit, 1 or more of them
(?=\d)   # until we see a digit ahead

[1] I say "usually" because you can change how some things behave, including that class, and because different regex flavors behave differently across languages.

[2] I used /[^\d]+/ -- "not a digit, at least once but also could be many times" -- because if I just did a straightup wildcard, the engine would just chomp on down to the word old, and I'd have one big old match, which is the opposite of what I wanted. Since I knew the next question started with a digit, I wanted to grab everything AFTER the question number that WASN'T a number -- because it would be part of the question I was on. Basically, you think of the question as delimited by the numbers. Also, negation is often faster.

ELI5: Why cast to an interface?

Max Cerrina — Sun, 10 Dec 2017 16:51:12 +0000

So, I am super new to OOP and Java--specifically, just finishing up my first semester of it.

I understand interfaces are akin to contracts, and understand the uses of them; similarly, I understand casting, etc. I understand you can cast to an interface, but I don't get why you would want to. I've checked a number of books, a number of sites, read some arguments on the topic on SO, and have yet to actually get the point of doing so.

Specifically: if you had an interface called Forecastable and two classes, Weather and StockMarket, both of which implemented Forecastable--and thus must have the methods of the interface, and thus any object instantiated in them has access to those methods by definition--then what would the actual use be of casting either some Weather or StockMarket object be to Forecastable, if they can both already access those methods inherently?