For discussion: the term "lazy loading"

[matthew-dean]

The phrase "lazy loading" in Less's documentation has been bugging me. The Wikipedia entry for lazy loading says: "Lazy loading is a design pattern commonly used in computer programming to defer initialization of an object until the point at which it is needed."

In Less's documentation, we say: "Variables are lazy loaded and do not have to be declared before being used."

Variables that do not have to be declared before being used is not the same as lazy loading. Lazy loading would be a scenario in which the value is declared but not initialized until it is called. Meaning, if the variable were never referenced, it would never have a value.

I'm not trying to be nitpicky, but it sounds like we're using imperative language to explain a declarative behavior, just to have it make sense to people? However, since lazy loading is a common term in web development (often used for delaying retrieval of images until they're about to be displayed), it gets confusing that it doesn't quite match the same concept. My worry is that in an effort to simplify with a known term, we're actually being misleading and possibly confusing the behavior for people.

To me, it would seem what we want to say is that variables have one value per scope block, and that value can be referenced at any point in the same block. Which is sort of saying the same thing, but doesn't use a known term in a slightly incorrect way.

I believe the language this replaced was Alexis's original description that variables were "actually constants", which, unfortunately, was also not exactly true either. I'm just wondering if there's a clearer way to say this.

[seven-phases-max]

Hmm, this makes sense indeed... Though I wonder what would be an alternative too (in CSS it's simply a part of cascade definition (4.) but I guess that would sound even more confusing in that specific Less variables context No, correcting myself: cascade is more applicable to LDW which is related but not the same thing of course).

[matthew-dean]

@seven-phases-max Yeah, I know it's not altogether helpful that I'm not suggesting an alternative, except to say that I think it might be better to just describe the behavior without borrowing a term that doesn't really apply. As in, maybe something as straightforward as:

Lazy Loading Variable Scoping

Variables are lazy loaded and do not have to be declared before being used.

The last declared value of a variable within a scope sets the value for that scope. This means that variables can be referenced within a block before they are declared.

---

What do you think?

[seven-phases-max]

Variable Scoping

Unfortunately it does not expose the idea itself (it sounds more like a title of the docs section where it's to be described). In contrast, "Lazy Loading", even if it's wrong, already contains some hint of what this can be about... :(

[seven-phases-max]

Btw., "lazy evaluation" is in fact fits better... Though the article does not provide any examples that look like Less's case, but the definition itself suits very well, imho.

P.S. On the other hand, maybe it's confusing too (I know it fits better only because I also know that everything (roughly speaking) is evaluated at the very last stage of the compilation (i.e. when CSS is generated) and property: @variable; statement by itself actually means nothing at all until this stage comes... Hence "evaluation" is still confusing (because you need to also explain what this actually means in Less)... hmm.. need more ideas :)

[seven-phases-max]

The last declared value of a variable within a scope sets the value for that scope. This means that variables can be referenced within a block before they are declared.

This statement tries to combine both "Last Definition Wins" and "(pseudo) Lazy Loading" principles into one but that's probably not a good idea. I.e. "variables can be referenced before they are declared" simply because "they just can" (not really because "the last of the scope wins"), i.e. this is related but not necessary overlapping stuff... (Hence there're two separate examples in the docs section (actually 2 for LL and one for LDW).

[matthew-dean]

Well, what I was trying to illustrate is that the idea of a "final value per scope". That is relevant for when you can use that value, and what the value will be. So it is related to this concept. You interpreted "this means" as referring to the "last declared value". "This means" refers to "sets the value for that scope". So, my wording makes it ambiguous what "this" is, but the important concepts are "variables have a final value" and any reference within that block will return the same value.

As an interesting side note, when I was trying to look for some better wording, I came across an article of a guy arguing that "variables" in most languages are misnamed. The case we are using he would call just "variables", because like math equations, it is a single substitution that can happen in multiple places. In languages like JavaScript, he argued they should be called "assignables", because they are temporary references which can mutate.

So, I'm wondering if we could call them "single-state variables" (or something like that concept). Part of the problem with "lazy load" is that it's a "temporal" definition, which implies mutation, when really, we want to imply the opposite: that there's non-mutation when that block is being evaluated. So, in some sense, we're doing the opposite of lazy loading (depending on how you look at it).

[matthew-dean]

But you do make a point that we could separate the two points and say:

1. Variables can be referenced before they are "declared" (and describing it as something other than "lazy loading").
2. The last declaration of a variable in the current block is the final value.

I think those are currently separated in the docs anyway, with examples of each.

[JamesonNetworks]

I feel like this behavior would best be described as variable hoisting?

[seven-phases-max]

No, not really. It's quite similar, but even semantically "hoisting" does not fit very well, nothing is "raised up" (like variable decl. in JavaScript for example), and its not really only about "use before decl", instead its really about evaluating the variable value as late as possible so all together the feature is much deeper thing than any "hoisting" (so indeed, "lazy evaluation" is probably the closest term - at least I switched to that myself long ago. Unfortunately there's no easy topic-name/corresponding-link fallback mechanics in the docs codebase, so we'll have to keep the section name for some time to not break any external links).

[audinue]

I believe the term is forward reference.

Variables are forward referenceable and do not have to be declared before being used.