Yes, I promise I've read the Contributions Guidelines (please feel free to remove this line).

Please type "I already searched for this issue": I already searched for this issue Edition: (1st or 2nd) 1st Book Title: ES6 & Beyond Chapter: Syntax Section Title: Nested Defaults: Destructured and Restructured Question: The example of setting defaults for a nested object's properties with the help of object destructuring:

({
	log: {
		warn: config.log.warn = defaults.log.warn,
		error: config.log.error = defaults.log.error
	} = {}
} = config);

I couldn't figure out why the trailing part ={} is necessary if at all, because removing it makes no different to the result, and it doesn't make any sense logically. Let's consider a more concise one, e.g. ({log: AA = {}} = config), the way I reason about it is that if there's no log property within config, then variable AA is set to {}; however, you clearly not able to set

{
    warn: ...,
    error: ...
}

to {}, right? Because it's not a valid assignment expression, or is it? Even if it's syntactically valid, we know that config.log is already set to {} with config.log = config.log || {}; in the code listing, it still seems unnecessary.

So, what role exactly the ={} part is playing and why it's necessary? Or is it a mistake? Thanks.

Because it's not a valid assignment expression, or is it? Even if it's syntactically valid

Yes, this would be syntactically valid, but not as useful as one might expect:

({
   log: {
      // ..
   } = { whatever: 42 }
} = config);

...is necessary if at all, because removing it makes no different to the result

Doesn't matter here, but in general all nested destructuring patterns need a default so as to not fail if the nested object/array to be destructured is actually missing. This is a consistency of coding style sort of thing.

thanks!

I am not planning to release the old LABjs 2.0.3 onto npm, but the long-running (many years now) effort to rewrite the 3.0 branch, yes, the plan was to put that out on npm (and thus it would be available for jsDelivr and other CDNs).

The 3.0 rewrite was mostly complete, but I stalled out because creating a test environment for script loading is actually really difficult. I was actually building a virtual-DOM sort of thing to fake those behaviors so I could have proper testing, but I never quite finished that effort. Would love help with it. :)

I already searched for this issue

Edition: 2nd

Book Title: Get Started

Chapter: Appendix B: Practice, Practice, Practice!

Section Title: Suggested Solutions

Topic: Suggested solution for "Comparisons" (Pillar 3) practice Suggested solution for "Closure" (Pillar 1) practice

@getify, It is really awesome practice samples! Despite the fact, that I have been writing JS-code for quite a long term, It took me a lot of time to solve them without tips 😅 They make me think for more elegant solutions!

I carefully checked my solution with yours by examining your source code and came across a few code style shortcomings Which, in my opinion, should be fixed to improve code readability

1. Suggested solution for "Comparisons" (Pillar 3) practice The simpler case typeof meetingStartHour != "string" || (...) should be handled first to avoid over-nesting Makes sense?

2. Suggested solution for "Closure" (Pillar 1) practice Statement else seems like just redundant as for me

I apologize in advance for my excessive pedantry in the scope of code style

Taking this opportunity to express my deep gratitude to the author for a series of these books!

The original code shows:

obj.a;			// 12
obj.b;			// 30
obj.c;			// 3

But I made the calculation and the result must be:

obj.a;			// 6
obj.b;			// 33
obj.c;			// 3

Because we call to changeObj( 3, 11 ); and:

	obj.a = a * 2;
	obj.b = b * 3;

The final value of the property c is OK because a + b + old value of c is 6 + 33 + 3 that is 42.

Thanks!

Yes, I promise I've read the Contributions Guidelines (please feel free to remove this line).

Specifically quoting these guidelines regarding typos:

Typos?

Please don't worry about minor text typos. These will almost certainly be caught during the editing process.

If you're going to submit a PR for typo fixes, please be measured in doing so by collecting several small changes into a single PR (in separate commits). Or, just don't even worry about them for now, because we'll get to them later. I promise.

Please type "I already searched for this issue":

Edition: (pull requests not accepted for previous editions)

Book Title:

Chapter:

Section Title:

Topic:

This is an old book (not being updated after 5 years) and the API in question also doesn't exist anymore.

OK, it's a minor nit, which I don't typically indulge (especially after a book has been published for almost 9 months). But I can see where there's a little confusion, so I will keep this issue open for if/when I do a future errata update.

If it read "Not all languages treat functions as values, but that's essential..." would it read clearer to you?

Ahhh, so you're talking about early-return pattern in both suggestions. Yeah, so that's my response to both then. Thanks for the feedback.

The simpler case typeof meetingStartHour != "string" || (...) should be handled first to avoid over-nesting Makes sense?

That would involve introduction of the "early return" pattern. This is historically a disputed pattern, meaning that some very much believe in it and others very much don't. In this case, for a book aimed at pretty early beginners, I don't want to get into that debate. As you said, it's a stylistic choice, which is why I'm encouraging readers to write whatever feels best to them. These solutions are described as one option, not the canonical best option.

Statement else seems like just redundant as for me

It's not... this range(..) utility does something different if you omit the second parameter (end) vs passing one in. If you omit (the === undefined case), it returns a function to be called later, which basically defers the calculation of the range until that later time. That inner function is where the closure is (remembering start), so it's pretty central to the point of this exercise.

But if you pass in anything (non-undefined, even null), the value passed for end is coerced to a number and the range is calculated and returned right away.

So these two clauses (if and else) are absolutely distinct.

From: https://github.com/eight04/cjs-es#import-style

Note that if the identifier is used as the callee of a function/new expression, it would be considered as the default member since the namespace is not callable.

Need to check for this corner case and avoid the namespace import in that case.

It is written

The value "z:last" is only applied to the z parameter in the case where f(..) is called with exactly two arguments (matching x and y parameters). In all other cases, the "z:last" will just be the rightmost argument, however many arguments precede it.

but when only one argument is passed as in the second example the "z:last" is not assigned to the right most arguments.

I have windows 10 + WSL (v1). I just installed this tool and tried to use it on a file inside WSL... I was expecting it to move the file to my Recycle Bin. It didn't work, but then I realized it put the file (renamed) inside ~/.local/share/Trash/files/ (according to that linux spec I guess).

I now realize this wasn't going to work like I expected since the tool is running in a linux environment (WSL), not actual windows.

I'm not sure if there's any way to get this tool installed out in windows land and still be able to run it from inside WSL to do what I expected, but if that's possible it would be nice to add something about that to the documentation.

Alternately and minimally, it might be a good idea to point in the docs out that installing under WSL in Windows is actually installing in linux, and pointing out where deleted files will go. Could remove some future confusion I had for the last ~20 minutes.

f(1);  // 1 "z:last"

Here "z:last" is the "rightmost argument" (aka "the last argument")... Note that I didn't say "rightmost parameter". In a variadic-functions language, you are free to pass as few or as many arguments as you want no matter how many parameters are declared. This utility (as with pretty much all others) is applying its logic to the arguments, not the parameter; a function can't really pragmatically self-inspect its own definition to apply logic based on declared parameters.

Please type "I already searched for this issue": I already searched for this issue

Edition: (1st or 2nd) 2nd

Book Title: Scope & Closures

Chapter: 1

Section Title: What's the Scope?

Question: In the section "Compiler Speak" where you enumerate all the source and target variables, you mention there are 5 target variables, I am wondering why we don't count the first argument of the console.log() function in the last line of the code: console.log(nextStudent); As I understand the function log() takes an obj1 parameter (see MDN documentation), so why don't we count this as a target variable for the same reason we count the studentID parameter as a target variable when getStudentName is invoked?

Hi !

Here is a pull request for the Perl port of JSON minify. Status: Port is complete and all tests pass. The Perl modules is not yet finish but I can go on with it while merging in getify perl branch. Once perl Module will be OK I'll post on CAPN (comprehensive perl archive network) and I'll update README to describe install from sources (repo) and from CPAN archives (distrib).

I don't know much about Perl, but this looks reasonable to me. Thanks for sticking with this! Merging. :)

The nextStudent there is an argument, not a parameter. The difference is in what's passed in at the call-site vs what's received in the function signature. An argument is a value or source-reference variable, whereas a parameter is a target-reference. If we were showing the implementation (internally in the engine) of the log(..) function, we'd potentially list out a parameter name for that first parameter, and that would be a target-reference.

Resolves #1693

Yes, I promise I've read the Contributions Guidelines (please feel free to remove this line).

Specifically quoting these guidelines regarding typos:

Typos?

Please don't worry about minor text typos. These will almost certainly be caught during the editing process.

If you're going to submit a PR for typo fixes, please be measured in doing so by collecting several small changes into a single PR (in separate commits). Or, just don't even worry about them for now, because we'll get to them later. I promise.

Please type "I already searched for this issue":

Edition: (pull requests not accepted for previous editions)

Book Title:

Chapter:

Section Title:

Topic:

Not accepting changes to the first edition books, per contributions guidelines.

Please type "I already searched for this issue": I already searched for this issue Edition: (1st or 2nd) 1st Book Title: Up and Going Chapter: Foreword Section Title: Foreward Problem: jennlukas.com seems to be no longer used (checked Jenn's twitter and she doesn't seem to be linking to it herself either)

Not accepting changes to the first edition books, per contributions guidelines.

I wish there was a way to determine how many usages of userland "cancellation" semantics on promises are about affirmative cancellation vs just disinterest. My intuition (based mostly just on some anecdotal observations in different code bases) is that the later is greater than the former. But it seems like if there was any way to gather evidence like that, it would help inform the design decisions here. If the majority use-case is actually dis-interest, unthen(..) might be enough.

I actually saw this as one of the goals of this feature.

It could be, it's just surprising to me because it's not how UMD's global behavior is typically construed. I'm just very used to being able to load a UMD via a <script> and get basically the same result as if I loaded the source itself. I may be projecting those assumptions onto others, but I was just thinking it would surprise others too.

OK, but I thought those you were saying those lines themselves were actually in the UMD boilerplate, seems like I misunderstood.

Let me illustrate the problem this way:

If you take the current snippet, and load that JS file with a <script> tag in a page, you end up with two globals, MyModule and bar. But if you "built" that file with this hypothetical mode of moduloze into UMD format, and loaded that UMD format into the browser with a <script> tag, you have just one global named m or Mz843242394 or whatever.

See this line of the UMD boilerplate:

https://github.com/getify/moduloze/blob/0e20280ae0fadf950a2c1fbe97ee602e9cac19df/src/umd-template.js#L12

The context[name] = .. statement just creates a single global variable of the name name, so since there's no destructuring there, it won't be creating the multiple global declarations (MyModule and bar).

Typically, the "global mode" (via <script> load) of a UMD wrapper is supposed to produce the same sort of effect as if the file wasn't wrapped in the UMD wrapper. If the .js file has a single global declaration (aka "export"), that could still be the case. But in the case where your .js file is declaring multiple globals, the typical UMD boilerplate doesn't have a way to create all those globals from its single "export" assignment.

I was assuming that these two snippets from your previous message were implying what the UMD boilerplate itself would be doing, which has destructuring in it:

const { MyModule, bar } = m;

define(['m'], function ({ MyModule, bar }) {
  ...
});

Did I misunderstand your intent there?

I think that answers 1 and 2

Eh... not exactly. You've implied a change to the way the UMD boilerplate works, where it's assuming a destructuring of a namespace as opposed to just getting a single value out.

But I can't really think of any way for moduloze to determine, reliably, that you definitely want the destructuring applied for one module's imports, and not for another's (the current status quo). For example:

define(['m','p'],function DEF({ MyModule, bar},Whatever){
   // ..
});

It would have to somehow semantically analyze how a module was being used after import and make a guess. That seems intractably complex given that we're talking about a non-static-module-format in a non-static language.

it wouldn't work right now because of the random names.

It internally works, meaning the modules can all reference each other just fine and all auto-execute. But it doesn't externally work, meaning if another non-moduloze-processed part of your app wants to access these resources, they won't have a name to do so.

But that's not Moduloze's fault, it's the fault that you're talking about a packaging format (UMD/AMD/etc) that requires names but you haven't given it names to use. That's a weakness of the module format, not of the tool.

But I'm wondering if it could, if:

I considered implementing some sort of algorithm to name the resources based on the URL, but ultimately decided that the complexity wouldn't be practical, because even those names would still be problematic in that they wouldn't necessarily always be intuitive/predictable. For example, should those identifiers be camelCased, or CapitalFirst or should they be snake_case, etc? So many nuances and variations, whatever I picked and baked in, would be too difficult for people to rely on in their apps.

It would also mean that the moduloze's naming convention choices implicitly become part of the business logic of any app using it, which means that moduloze is now much more restricted in future changes in that respect (without causing breakage, not to mention the complexity of using modules that were compiled by different versions of moduloze, etc).

if we wanted to integrate this as a feature at jsDelivr, we'd probably want it to be zero-config from the user's perspective.

That makes sense. Unfortunately, there's nothing we can do about the fact that some module systems (like browser globals, AMD, and... ultimately, UMD) require names to load and use modules, not just their URLs. That basically requires some sort of meta-data, either that you (the CDN) are made aware of, or that the author is aware of and uses in their own build.

An author couldn't manually distribute their modules out on jsDelivr (or any CDN) in the UMD/AMD/globals format without having chosen a name for them, or nobody could consume and use them. That's just part of the authoring/distribution process if you plan to support a name-required packaging format.

So I agree, it seems like you can't build them automatically without some source for those names.

Of course, that limitation only applies to UMD. You could still host a service running a tool like moduloze to up-convert from globals/CJS to ESM (minus the index/rollup build), and just not offer the UMD conversion/hosting at all. The benefit of upconverting to ESM should standalone, even if you couldn't take advantage of also upconverting to UMD.

Or, for the UMD support specifically, you could pick some sort of convention, as suggested, like inferring from the filename, or maybe requiring each to be in its own directory and using that name, etc. Then you'd just need to programmatically specify the dependency-map as part of the call to moduloze.

But ultimately, whatever convention you pick there, it'd have to be something that the authors documented for their users, so users knew what identifier names to use in their apps. This seems really brittle for your CDN, with the exact same drawbacks as me baking that stuff into the tool.

The other option is to pick like a convention similar to source maps, where each file to be converted to UMD has to have a "{FILENAME}.umd-map.json" alongside it, providing a name to use. Or whatever other ideas we may bikeshed. That's not exactly "zero configuration", but it doesn't seem all that unreasonable (especially since people and tooling already do sourcemap files similarly).

In UMD builds, the dependency-map is "required" for several reasons, to map resource URLs to their names:

1. The name of a resource is used by the browser-global aspect of UMD behavior as the registered global identifier (aka, "the export").

2. The name of a resource is used by the AMD aspect of UMD behavior to register a module definition by its name (aka "the export"), so that this name can later be used by other modules.

3. The name of that resource is then used by the AMD aspect of UMD behavior in the list of dependencies passed to an AMD module's definition, so that AMD knows which dependency instance(s) to retrieve from its internal definitions and provide to (aka "import for") this module. That same name is also used as the actual parameter identifier in the outer definition function for a module that needs that dependency.

So, if you require(..) some URL that Moduloze doesn't have a name for (no dependency map, or not listed), Moduloze has to generate a unique name (like Mz8382423923) for it, for it to be used in all those various ways.

If the dependency is never referenced elsewhere in the app by some other name, this auto-generated name is probably not a problem. But it absolutely might "break" your app if you're just assuming that "MyCoolModule" will be able to reference it from somewhere else, but you didn't tell Moduloze that name.

That's the main purpose of the dependency-map.

Secondarily, ESM uses the dependency-map if you're also building the "index" / "rollup" ESM module (the one that imports and re-exports all your modules as a single module). It needs names to use in all its re-exports. Of course, if it used auto-generated names for those, none of your code would know (or be able to predict) those bindings, so it'd be unuseful.

BTW, I definitely think something like this discussion should make its way into the "Conversion Guide" docs. That's an open TODO. :)

[Editor: this question was moved here from another thread]

@MartinKolarik:

I briefly checked how moduloze currently works with other formats and I noticed there's a required config option dep-map. I guess it's needed to map require() to UMD globals but I see it's somehow used in ESM processing as well. With an empty map, both ESM and UMD outputs look like I'd expect though. Can you explain briefly why the map is needed to make sure I understand the current approach for UMD/ESM?

Shouldn't bar be exported as well since it's in the global scope? Or do you expect the user to specify which (only one) global is exported?

Yep, it probably should be exported as well. Just overlooked it. Though, that does bring up pesky questions...

1. basically, all global declarations in such a file could be assumed to be needed, so they can all be named exports easily for both ESM and the CJS side of UMD. But what about multiple named exports for the browser globals and AMD sides of UMD? it doesn't really support that.

2. if there's only one global, should it also be a default export (ESM)? should it be the "main export" of the UMD form? would this be INSTEAD OF, or IN ADDITION TO, the named export?

3. but if there's multiple globals, do we do no default exports, or just pick the first one?

https://twitter.com/LeaVerou/status/1285320583408955401?s=20

Thanks!

The case items themselves should be seen as they are all in one scope.

This isn't entirely true, since if you put { .. } around the statements of a single case clause, that is a nested block-scope.

@KarenEfereyan This isn't really a "project" per se. It's a series of books I wrote (and am writing). Contributors are primarily those who find typos that my copyeditor may have missed, or occasionally find technical mistakes (such as this thread).

Good catch, thanks.

Yeah, they're definitely sending back a fully qualified path:

[{
    "filePath": "/mnt/c/Users/whatever/Desktop/test.js",
    "messages": [{
        "ruleId": "no-floating-decimal",
        "severity": 2,
        "message": "A trailing decimal point can be confused with a dot.",
        "line": 1,
        "column": 9,
        "nodeType": "Literal",
        "messageId": "trailing",
        "endLine": 1,
        "endColumn": 11,
        "fix": {
            "range": [10, 10],
            "text": "0"
        }
    }],
    "errorCount": 1,
    "warningCount": 0,
    "fixableErrorCount": 1,
    "fixableWarningCount": 0,
    "source": "var x = 1.;\n",
    "usedDeprecatedRules": [{
        "ruleId": "handle-callback-err",
        "replacedBy": []
    }, {
        "ruleId": "id-blacklist",
        "replacedBy": ["id-denylist"]
    }, {
        "ruleId": "no-buffer-constructor",
        "replacedBy": []
    }, {
        "ruleId": "no-catch-shadow",
        "replacedBy": ["no-shadow"]
    }, {
        "ruleId": "no-native-reassign",
        "replacedBy": ["no-global-assign"]
    }, {
        "ruleId": "no-negated-in-lhs",
        "replacedBy": ["no-unsafe-negation"]
    }, {
        "ruleId": "no-new-require",
        "replacedBy": []
    }, {
        "ruleId": "no-path-concat",
        "replacedBy": []
    }, {
        "ruleId": "no-restricted-modules",
        "replacedBy": []
    }, {
        "ruleId": "valid-jsdoc",
        "replacedBy": []
    }]
}]

So, if the plugin sends in just a filename, could the plugin then strip off all but the response filename, and then fully qualify it based on the current working directory?

BTW, if I try to specify a custom location for the config file via the args array, I get an interesting error that seems to indicate that SL is trying to parse out and handle configs manually?

args: ["-c ~/some/other/config.json"]

The error is:

Value for 'config' of type 'path::String' required.

If I instead do:

args: ["-c", "~/some/other/config.json"]

I get the path munging problem, where that the error reported says the config can't be found and what it reports is a really messed up path string.

I added those to my config, and this is what the error says now:

SublimeLinter: WARNING: eslint reported errors coming from '\mnt\c\Users\whatever\Desktop\test.js'. However, reading that file raised:
  [WinError 3] The system cannot find the path specified: '\\mnt\\c\\Users\\whatever\\Desktop\\test.js'.

So, the path munging problem seems to have been fixed, or at least significantly improved? But it's still not working.

Notable that, from the perspective of eslint inside WSL, the path \mnt\c\Users\whatever\Desktop\test.js is completely valid. But that path makes no sense outside of WSL, so I would guess this error is that SL doesn't know what to do with that path?

If we just send the filename (not the absolute path), no linter will probably make sense of it. They will assume this is relative to the working dir.

Understood, that makes sense. Would it be impractical to change the CWD to where the file being linted is (usually, just the current open file, right) before sending it to eslint, and then perhaps revert the CWD back after getting the results back?

Also... I just tried this from the CMD windows command line:

C:\Users\whatever\Desktop>wsl eslint -c ~/.eslintrc.json test.js

/mnt/c/Users/whatever/Desktop/test.js
  1:9  error  A trailing decimal point can be confused with a dot  no-floating-decimal

✖ 1 problem (1 error, 0 warnings)
  1 error and 0 warnings potentially fixable with the `--fix` option.

IOW, if I provide a single filename to eslint, it works properly. It's only if I tried to provide a fully qualified (or relative) path that I see the path issues cropping in.

Would it be feasible for SL (and the eslint plugin) to only provide just the filename (in the cross-wsl boundary call) and not a full path?

So, just to clarify, this is a problem without a workaround, as far as the current situation is concerned?

I don't know any python, but I wouldn't mind trying my hand at a PR, if you had any suggestions about approximately where such path-translation logic might need to go?

OK, so I'm now getting errors like this:

SublimeLinter: WARNING: eslint reported errors coming from '\mnt\c\Users\whatever\Desktop\C:UserswhateverDesktoptest.js'. However, reading that file raised:
  [WinError 3] The system cannot find the path specified: '\\mnt\\c\\Users\\whatever\\Desktop\\C:UserswhateverDesktoptest.js'.

So I take it that's what you meant about the path problem?

Oh, also, there's a command called wslpath you can run to translate paths. It's (perplexingly) inside of WSL, but you can access it from the outside like this:

wsl wslpath
Usage:
    -a    force result to absolute path format
    -u    translate from a Windows path to a WSL path (default)
    -w    translate from a WSL path to a Windows path
    -m    translate from a WSL path to a Windows path, with '/' instead of '\'

Just curious, why does the linter need to send it a filename/filepath? Does it not feed the contents of the open file directly to eslint? How does it lint while typing if you haven't saved a file yet?

BTW, here's my full SL config:

{
	"delay": 5,
	"gutter_theme": "Default",
	"highlights.demote_while_editing": "all",
	"highlights.time_to_idle": 5,
	"lint_mode": "load_save",
	"linters": {
		"eslint": {
			"executable": "\\\\wsl$\\Debian\\usr\\local\\bin\\eslint",
			"disable": false,
			"args": ["-c ~/.eslint.json"],
			"excludes": [],
			"styles": [
				{
					"priority": 1,
					"mark_style": "none"
				}
			]
		}
	},
	"show_marks_in_minimap": false
}

I have installed SublimeLinter plugin for ST3 install in windows 10, as well as the sublimelinter-eslint plugin. However, I'm having trouble getting it to start correctly.

I have eslint installed inside my WSL instance, so from windows, to execute binaries inside of WSL, the command is like wsl eslint", where that wsl program (provided by windows) does the bridging. If you run that command from a normal CMD prompt, it works fine.

However, when I configured SublimeLinter-eslint like this:

"executable": "wsl eslint"

I get this error in the ST3 console:

You set 'executable' to 'wsl eslint'. However, 'which wsl eslint' returned nothing. Try setting an absolute path to the binary.

I tried changing the path to:

"executable": "\\\\wsl$\\Debian\\usr\\local\\bin\\eslint"

From inside the WSL terminal, you can run /usr/local/bin/eslint and it definitely runs. But unfortunately, when I set that absolute path, I get a different error in the ST3 console:

SublimeLinter: WARNING: eslint cannot locate 'eslint'

So I'm stuck, not sure what to do?

Good catch, thanks!

That's not re-assigning the BLUE special... that's mutating the contents inside the object that the BLUE special points to, by virtue of a copied reference to that object. Those are entirely different things. There is absolutely no way to access the shadowed BLUE special as a lexical identifier, meaning there's no way to re-assign it.

Yes, I promise I've read the Contributions Guidelines (please feel free to remove this line).

Specifically quoting these guidelines regarding typos:

Typos?

Please don't worry about minor text typos. These will almost certainly be caught during the editing process.

If you're going to submit a PR for typo fixes, please be measured in doing so by collecting several small changes into a single PR (in separate commits). Or, just don't even worry about them for now, because we'll get to them later. I promise.

Please type "I already searched for this issue": I already searched for this issue Edition: (pull requests not accepted for previous editions) any Book Title: any & all Chapter: any & all Section Title: any & all Topic: any & all

It just allows people to use gitpod on the repo with preinstalled extensions that you as an author to give guided codetours, pair programming with codetogether, etc. The hope is to make your content more interactive. I hope you try it out with an open mind 😄

Appreciate the screencapture illustrating what you're referring to. I don't think that's a broadly applicable enough experience to roll into the main repo, but that's a perfect example of something you can do when you fork the repo and want to customize your experience.

https://github.com/mdn/mdn/issues/98#issuecomment-673513692

If we're talking about the spec, function isn't its own specific type (despite the typeof behavior), it's a sub-type of object.

If we're talking about developer ergonomics, function is definitely its own type since it has very specific behavior that other object values don't have.

So... it depends.

For the record, the same can be asked of arrays... the spec says they're a subset of object, but they definitely have special behavior we rely on that's different from normal objects.

I hope you try it out with an open mind

You didn't really provide any context, so how could I have an open mind? I've never heard of gitpod, so I haven't the faintest clue what you're asking me to enable. And the diff isn't clear either. Adding a random .yml file without any context is not on my priority list.

I googled gitpod, seems like it lets you make docker images from github repos. But still, that doesn't explain at all how you're proposing that this would make this repo "more interactive"? Moreover, being "interactive" is not particularly a goal of this repo.

I'm confused as to what I'm supposed to think of this contribution?

Polling your own followers means

Assuming that (most/all) of my followers agree with me, or are even biased to tend to agree with me general, is a flawed premise. To my surprise, I quite often have quite vocal opposition to opinions I share, even from my most ardent of followers. A lot of people follow me if for no other reason than to share differing/opposing opinions with me.

Morever, most polls that I post "only to my followers" only get a few hundred responses at most. In this case, I knew that for the results to be more useful, it needed to expand to a broader audience. I ran it for 3 days instead of a few hours like I normally do, and I explicitly asked for additional responses in several different channels (linked-in, some different slacks I'm in, etc). I also asked for RTs (56 suggests it was spread around somewhat beyond my circle), even those in other language communities that definitely aren't my followers or even know who I am.

Of course, I don't know who responded. But to have 1,240 responses to one of my polls is 3-5x what I would normally expect, so I think it highly unlikely that the majority of these responses were from my followers wishing to just "yes vote" affirm whatever I say.

...skewed...what could be seen as your expectations, even if just from context cues.

I also tried to make the wording as neutral as I could manage so as to not suggest my opinion on the topic. I haven't talked about this issue before publicly on twitter, so my followers wouldn't have any way of knowing how I feel, unless they had also found and read this thread.

Insofar as it's possible to pull any sort of useful evidence from online polls or surveys, I think I did a reasonable job of trying to get fair feedback. I wouldn't have posted results here otherwise.

Thank you, I will pick this up in the next round of errata updates.

I guess let this stand as a monument to motivated reasoning

Agreed, I think we're making progress in this thread (even if we're not agreeing) in that we're finding ways to articulate valid (if opposite) viewpoints more clearly.

But you only ever see something for the first time once

This is true.

But what's also true is that programmers are not machines, so they don't always "see an unfamiliar thing once, look up the answer, get a perfect understanding of it, then move on and never forget or have further confusion". The reality, IME, is often much messier.

This is especially true since we're talking about syntax, and the # character is not something that will be easily google'able to find this exact new usage. I can't tell you how many times I've had people complain about not knowing what to call some operator or syntax, like the ?. for example, in their searches. Finding relevant material on these things is very challenging when you don't even know what to call it. And even if they get lucky and find something relevant, the materials are often imperfect (or flat out wrong).

So it turns out that the process of going from "I've never seen this before" to "I know and recognize that, and have a solid understanding of what it is", is a lot more complex than flipping a bit. That's why those first impressions/intuitions factor heavily in the early learning of a feature -- they guide initial mental models, assumptions, and even the words we use to google or stackoverflow to ask for help.

Here's an illustration of how the book's version of thunkify(..) utility is "broken":

function thunkify(fn) {
	return function() {
		var args = [].slice.call( arguments );
		return function(cb) {
			args.push( cb );
			return fn.apply( null, args );
		};
	};
}

var f = thunkify((x,y,cb) => cb(x + y));

var seven = f(3,4);

seven(sum => console.log(`Seven: ${sum}`));    // Seven: 7
seven(sum => console.log(`Another Seven: ${sum}`));    // Seven: 7     <---- Oops
seven();   // Seven: 7    <------- WHAT!?

We would have expected the next-to-last line to print Another Seven: 7, but it didn't. The shared closure over args modified the list in the first seven(..) call to add the first version of the callback. From then on, all subsequent calls to seven(..) don't pay any attention to what callback you pass in.

Compare to the corrected thunkify(..):

function thunkify(fn) {
	return function() {
		var args = arguments;
		return function(cb) {
			var thunk_args = [].slice.call( args );
			thunk_args.push( cb );
			return fn.apply( null, thunk_args );
		};
	};
}

var f = thunkify((x,y,cb) => cb(x + y));

var seven = f(3,4);

seven(sum => console.log(`Seven: ${sum}`));     // Seven: 7
seven(sum => console.log(`Another Seven: ${sum}`));     // Another Seven: 7

So, yes, the book's version is broken and that's regrettable. But it was enough of a substantive change (and would have needed corrective text to explain), and the book had already been out for quite awhile at that point... so I opted not to modify the book. At some point, a second edition will be written, and this issue will be addressed then.

I would like to enter this tiny piece of highly anecdotal evidence into the discussion record on the recent debate of if #foo = #{ a: 1 } "...is clear about what’s what"?

(https://twitter.com/getify/status/1291707811009830913)

Don't read too much into my intent of asking the poll or sharing it here. Twitter polls are clearly neither scientific nor definitive, and no poll wording is ever perfect. And it's also asking a very narrow question, about first impressions of a syntax, at a glance.

But my claim earlier was that if I glanced at a line of code that used the # on both sides of the =, my first instinct would be to think they were in some way related. I was extrapolating that, from my experience with lots of new learners of JS, it might be the case that others would infer a relation/connection. I was imagining initial incorrect assumptions like "private fields are only supposed to have tuples/records assigned, not objects/arrays" or "you're only supposed to assign tuples/records to private fields, not normal properties".

I combat a lot of assumption/inference based incorrect information out in the wild as blog posts about JS topics spread around the community. It's why I'm cautious of designing things that could contribute to that trend.

54.4% to 45.6% is not overwhelming proof by any means, but I do think it's somewhat suggestive that it's perhaps not quite as "clear", "obvious", and "unambiguous" as is claimed. 1,240 votes might not be enough for a truly representative sample, but it's certainly more than the few of us who are discussing the topic here.

I'm not saying this is definitive strong evidence against the syntax. But I do think first impressions, intuitions, and inferences about syntax design should at least be considered. At a minimum, those concerns should influence how the eventual feature is named, discussed in the spec and associated blog posts and early code examples, etc.

are significantly different.

I don't consider glancing at a simple assignment statement and seeing # on the left and on the right, in the first position of both sides, no doubt, "significantly" different. That's not an assertion of them not being technically different, it's an assertion of them not looking a lot different, especially at a glance.

I don't care to get into a debate about what's allowed to be subjective or not.

#foo = #{ a: 1 } is clear about what’s what.

Not to my eyes. To me that's the opposite of "clear". I look at that and have to double take to confirm in my mind that the two #s aren't related. My only point is that it's subjective, yet repeated assertions in this thread like "obvious and unambiguous" keep making the opinion sound like it's objective.

Some character encoding issues in the "Get Started" ebook PDF (leanpub) and print (from Amazon):

• in the ebook version, in the Foreword, page 9 (page “i" of the text), second paragraph, third line: — instead of “—" • in the ebook version, in Appendix A, page 120 (page “102” of the text), next to last line of the page: — instead of “—" • in the ebook version, in Appendix B, page 132 (page “114” of the text), third to last line of the page: — instead of “—"

Fixed this with settings at leanpub.

I already searched for this issue :upside_down_face:

Replace reel.display.call(slot) with simpler (and more illustrative of the point!) slot.display().

Some character encoding issues in the "Get Started" ebook PDF (leanpub) and print (from Amazon):

• in the ebook version, in the Foreword, page 9 (page “i" of the text), second paragraph, third line: — instead of “—" • in the ebook version, in Appendix A, page 120 (page “102” of the text), next to last line of the page: — instead of “—" • in the ebook version, in Appendix B, page 132 (page “114” of the text), third to last line of the page: — instead of “—"

Thank you!

OK, I just published v0.4.2 which fixes the bugs with a missing .mzrc or dependency-map.

Perhaps you could re-try it now with the update?

Currently, a missing ./.mzrc config file throws an error. It should just silently move on with defaults.