DEV Community: TinyNight(JP)

How to Remember Namespaces

TinyNight(JP) — Mon, 03 Aug 2026 03:14:30 +0000

I often see people using the term "namespace" incorrectly. Even when explanations of what a namespace is are presented, they only go as far as describing its function, neglecting to properly define the name "namespace" itself.

Definition of the Namespace

A namespace is literally the space to which a name belongs. If we were to classify the term namespace, it would be a specification (concept), not a tool.

In namespaces, the higher level is represented as outer and the lower level as inner. In terms of class structure, this corresponds to outer classes and inner classes. In other words, to explain it from a different perspective, it looks like this.

Representation of namespaces from the outer perspective

Build namespaces (best)
Define namespaces (to fit many programming language implementations)
Open namespaces (such as Ruby's class definition and module definition)
Create namespaces (such as the pseudo-namespace hack in older JavaScript)
Declare namespaces (such as the package declaration in Java or the namespace declaration in PHP)

Representation of namespaces from the inner perspective

Belong to a namespace (best)
Entering the namespace (This is entirely from an inner perspective, so it might feel out of place depending on the context)
Be included in the namespace (this is a reasonable explanation if explained objectively).

Incorrect expression

From the definition above, it is clear that the following expressions are incorrect.

Add/Paste a namespace (the expression "add/paste a space" is grammatically incorrect).
Use namespaces (not to the point of being completely broken, but treating namespaces as a tool)
Separate/Cut namespaces (While "Separated by namespaces" is understandable, "separate/cut" can be misleading)

Meaning of "Name" in Namespace

The "names" referred to here can be class names, module names, or package names. What they represent varies depending on the language that implements namespaces.

For example, in Ruby, it refers to constant names. In Ruby, class names (module names) are also constants, so outer refers to class name constants, and inner includes both general constants and class name constants. Since general constants cannot be outer, a structure is created where class name constants can be nested, but general constants cannot.

An easy-to-understand metaphor

Belonging to a namespace means that inner moves to a town called outer, and inner is included in outer's address book. Problems arise if an entity claims an address in another town without actually being in it (this example is easily illustrated by Ruby's constants ¹).

Alternatively, a tenant named inner would enter into a lease agreement with a multi-tenant building called outer, and inner would occupy a floor within that building. As a result, inner's address would be "inner tenant inside the outer building".

Ruby constants have a reference path that combines a lexical namespace and inheritance. When moving and referencing (physical nesting), you can reference the constants of the outer namespace, but when calling out the address from outside (adding a namespace prefix), you cannot reference the constants of the outer namespace. ↩

[Ruby] The True Value of Flow Control Operators

TinyNight(JP) — Fri, 31 Jul 2026 16:09:37 +0000

Introduction

Ruby has four types of logical operators: && / || / and / or, each with a different precedence.

&& / || have higher precedence as operators, with && taking precedence over ||.

and / or have low operator precedence, and there is no priority between them. In other words, they are evaluated from left to right.

These are sometimes described as being "also usable for flow control," but that statement is incorrect.

and / or are extremely powerful flow control operators. It's not an exaggeration to say they were implemented specifically for flow control (more on this later).

The suggestion that these should be used for flow control has been made for a long time, by "Ruby Good Idiom" and others, but the problem is that even those articles themselves misuse them, and as a result, they haven't become widespread. Even the official references downplay their usefulness.

In this article, I will explain these points in detail and discuss the true value of flow control operators.

Flow control syntax

As the name suggests, flow control operators are operators that perform "flow control." They combine the functions of controlling the flow and returning a value as an operator. The reason why and / or have no precedence is because they are operators for flow control. In other words, flow control operators can be rephrased as operators that control both the flow and the return value.

Since it is used for flow control, its essence is no different from control structures. In other words, using it by grouping it on a single line and nesting it is an incorrect usage that significantly reduces code readability and clarity of control flow.

If used correctly, it's best to place it at the end of a line, followed by a line break. Simply adhering to this rule alone is quite effective.

While the aforementioned "Ruby Good Idiom" uses this operator for exception handling, this is incorrect. This is because an exception is fundamentally something that goes outside the flow's control. If you're going to throw an exception, you should either throw it before entering flow control or after flow control, using a guard clause.

Examples of common control statements

When controlling the return value using common control statements, the code would look like this:

def test_method
  if a > 0 && b > 0 # Conditional comparison for calling a function.
    function(a, b) # The return value of the function will be the return value of test_method.
  else
    false # If the condition is not met, test_method will return false.
  end # If there is no else clause, the return value of test_method will be nil.
end

It's easy to understand, but it's redundant. It doesn't have a trace of idiomatic Ruby.

Example using logical operators

When controlling return values using logical operators, the following type of code is common.

def test_method
  a > 0 && b > 0 && function(a, b)
  # Returns false when the previous conditional comparison becomes false.
  # Otherwise, the return value of the function will be the return value of test_method.
end

While it's very compact, the code mixes two flows—conditional comparison and function call—into a single line, resulting in extremely poor code readability and clarity of control flow. This is a bad example of compressed notation, which is often seen in other languages as well. It goes against Matz's philosophy.
　

Example using flow control operators

When controlling the return value using flow control operators, the code would look like this:

def test_method
  a > 0 && b > 0 and # If the condition is met, proceed to the next step in the flow.
                      # If not satisfied, return false and exit the flow.
    function(a, b) # The return value of the function will be the return value of test_method.
end

Following the rules of flow control syntax, a flow control operator is used at the end of the line to create a new line.

The two flows—conditional comparison and function call—are visually separated, resulting in high code readability and clarity of control flow. Furthermore, there's no redundancy like in control statements. This demonstrates the extremely powerful syntax of Ruby's flow control operators.

Ruby method specifications

Ruby has a great many methods that return either a value or nil. This is intentional. In Ruby, a value (an object other than nil or false) is treated as true, and nil is treated as false. In other words, they can be evaluated with flow control operators. It can be said that this is a specification designed to control the flow and return value using flow control operators. They should be appropriately called flow control methods.

Sample code is shown below.

Example of controlling flow and return value with flow control methods

def find_employee(name)
  OFFICERS_LIST.find{|m| m.name == name } or
  EMPLOYEES_LIST.find{|m| m.name == name } or
  SECONDED_EMPLOYEES_LIST.find{|m| m.name == name } or
  nil # Does not exist.
end

This code is a method that searches three lists in order from top to bottom and returns the employee whose name matches. The flow control method find returns value (truthy) if the employee is found, so the flow control operator or stops there, and the found value becomes the return value of the method. If it is not found, the flow moves to the next list, and if it is not found at all, it returns nil to indicate that it was not found (it also behaves as a flow control method itself).

The flow control operators and methods work together beautifully, highlighting a simple flow structure completely free of unnecessary code. This is the world Ruby aimed for. This is the very essence of Matz's philosophy.

If you're concerned about the duplication in the name check part of the above code, you can simply convert the closure into a Proc and pass that instead. That's a very Ruby-like solution, after all.

Some of you might be thinking, "Isn't the final nil unnecessary?" And you'd be right, because the final find also returns either a value or nil, so the result wouldn't change even if it were omitted. However, it's necessary for visualizing the flow. It would be a waste to enhance the clarity of control flow with flow control operators only to hide it at the end. That's why I put nil here.

How to use `and` / `or`

As in the first flow control example, and serves to connect the conditional expression with the next flow. It's helpful to remember that it's an operator that advances the flow if the condition is met.

or serves to connect flow control methods, as in the last example. It's helpful to remember that it's an operator that advances the flow if no value is found (if nil is returned) by the flow control method.

summary

I hope this article has helped you reaffirm just how beautifully designed Ruby is. The elegant flow control using flow control operators, and the overwhelming readability when used in conjunction with flow control methods—Ruby is a human-centered language designed to make programming enjoyable.

Along with the previously posted guide on "how to correctly remember unless and until", I hope many Rubyists will find this useful.

bonus

Basic Guidelines for Flow Partitioning

As some of you may have noticed from this article and the sample code in the aforementioned unless article, negation operators (! and not) are not used at all, except in the bad examples. This is not because I chose those conditions and only used them. In fact, the inclusion of negation operators in conditional expressions is evidence that the flow has not been properly divided.

A clear code example is shown below.

return if !obj || obj.empty? # Commonly seen guard clause.

The example above is a typical guard clause that any Ruby programmer has probably written at some point. However, upon closer inspection, it contains two interwoven flows. If these flows are properly separated, it looks like this:

return unless obj    # Whitelist (except nil).
return if obj.empty? # Blacklist If the content is empty, do not allow it.

If flows are not mixed in this way, negation operators will basically not be mixed in. Therefore, if a conditional expression contains a negation operator, you should first check whether flows are mixed in. If conditional expressions and function calls are mixed in, as in this article, or if the whitelist and blacklist guard clauses are combined into a single guard clause, as in the example above, simply separating the flows in that section should dramatically improve the readability of the code and clarity of control flow.

Of course, it's impossible to eliminate them completely. For example, there are cases like !ary.include?(0) where there's nothing you can do. Implementing an exclude? method is an option, but this level of negation doesn't significantly reduce readability, so it's acceptable. The important thing isn't to eliminate negation operators. It's simply about improving readability and clarity of control flow through proper flow division.

Your past self is a stranger

This emphasis on readability might sometimes come across as uncouth or overly intrusive. However, those who have been programming for a long time will likely understand the experience of looking at their own code years or months later, after being away from the field for a while, and finding it incomprehensible—like looking at spaghetti code written by someone else.

Adding annotations with comments is fine, but doing so for every single line of code is redundant and looks bad. It's far better to separate the flow and design the code to speak for itself.

This is so important I'll say it twice: "Your past self is a stranger." Paradoxically, this means your future self is also a stranger. Even if you're developing a project on your own, or perhaps especially because you're developing it on your own, write code that won't confuse your future self. Because the consequences of that will undoubtedly fall back on you.

[Ruby] How to Truly Understand unless and until

TinyNight(JP) — Mon, 27 Jul 2026 06:13:06 +0000

I frequently see comments that 'unless' and 'until' are difficult to understand.
I've also heard that it's prohibited in tools like rubocop.
This is a fundamentally flawed way of thinking about unless and until.

As a basic principle, abandon the idea of "if it becomes false".
The basic principle is to remember what happens when the condition evaluates to true, and you won't get confused.

unless

Think of `unless` as an expression that will not be executed if the condition is met.

result = 1 if a && b     # If a && b is satisfied, execute the left side.
result = 2 unless a && b # If a && b is satisfied, do not execute the left side.

When combined with return (guard clause), it should be considered a condition for proceeding with the process.

return if a && b     # Terminate processing if (a && b) is satisfied.
return unless a && b # Proceed with processing if (a && b) is satisfied.

When using them as guard clauses, remember the following: The two have distinctly different roles.

Keywords	Role	Action
return `if` expression	blacklist	Terminate processing if the expression is satisfied
return `unless` expression	whitelist	Proceed with processing if the expression is satisfied

To differentiate their use, any judgment formulas that involve both should be separated.
An example is shown below.

def gagazet_gate(yevonite) # case 1
  return if yevonite == Kimahri
  # Blocks only Kimahri. This allows unauthorized people to pass through.
end

def gagazet_gate(yevonite) # case 2
  return unless yevonite == Summoner || yevonite == Guardian
  # Summoners and Guardians are allowed through. This means Kimahri can also get through.
end

def gagazet_gate(yevonite) # Bad case
  return if yevonite == Kimahri || yevonite != Summoner && yevonite != Guardian
    # "No passing if you're Kimahri, and also if you're not a summoner, and also if..."
    # Not Biran!
end

def gagazet_gate(yevonite) # Best case
  return unless yevonite == Summoner || yevonite == Guardian
  return if yevonite == Kimahri
  # Summoner may pass. Guardians may pass. Kimahri not pass!
  # Since these two guard clauses serve diametrically opposite purposes, they should be used separately.
end

until

The `until` statement can be thought of as a condition that exits the loop when it becomes true.

i = 0
p i while (i += 1) < 10 # Loops while i is less than 10
p i until (i -= 1) <= 0 # Exit the loop when i becomes 0 or less

For example, the following example is easy to understand. The formula is also elegant.

a = (1..100).to_a
a.shift until a.empty? # Exit the loop when a becomes empty

Summary

While it's often suggested that unless be replaced with if not, that suggestion is based on a flawed premise.
unless and until are not constructs that reverse the evaluation of if and while conditional expressions. Rather, they are constructs that "reverse the behavior" of a conditional expression.

Furthermore, until is actually more suitable for loop control than while because it clarifies the goal.
until is the true ace among loop constructs. It is definitely not just a variation of while.

Inference: The Essence of Psychological Burden

TinyNight(JP) — Thu, 23 Jul 2026 10:39:32 +0000

Translated from Japanese via Google Translate. Original text included at the bottom for reference.

Humans calculate psychological distance using the Pythagorean theorem, and psychological load is proportional to the computational effort involved.

Based on this premise, we can reason through and resolve questions often raised in various fields.

To proceed with this line of reasoning, we define the computational models for measuring psychological distance as follows:

Pythagorean calculation = A simple calculation to measure the "distance from the origin" using the Pythagorean theorem.
Euclidean calculation = A computationally intensive calculation that performs the Pythagorean calculation multiple times to measure the "distance between multiple coordinates."

The American World of Objective Perspective: A society that calculates Euclidean distances relative to countless others.; From this perspective, one must locate oneself within a vast space, necessitating strong self-assertion—even at the cost of significant resources. Failure to do so risks literally losing sight of oneself amidst the world.
The Japanese World of Subjective Perspective: A society where the self serves as the origin, allowing for calculations based solely on the Pythagorean method.; In this view, the self is already established at the origin, eliminating the need for aggressive self-assertion. This creates the mental space to be considerate of others (the spirit of *omotenashi*, or hospitality).

This distinction holds the key to unraveling the following questions.

The Japanese Ability to "Read the Air"

Since Japanese people need only calculate distances within a very narrow range centered on themselves, they can compute psychological distances quickly and with minimal mental effort. This results in a high aptitude for "reading the air" (sensing the unspoken atmosphere).

In contrast, Americans—existing in a world of countless Euclidean calculations—experience a kind of cognitive "overflow," wondering, "What is 'the air'? Where is it?" They perceive the Japanese ability to read the atmosphere as something akin to a superpower, finding it difficult to fully comprehend.

The Sanctuary of "Within Arm's Reach"

Americans possess a mental model that regards the space "within arm's reach"—the immediate vicinity—as their own personal sanctuary (or "personal bubble"). In this sanctuary, Americans are liberated from the world of countless Euclidean calculations. It is a precious interval allowing the brain—their CPU—to idle.

One could say that the American preference for oversized food is a defensive instinct of the brain, designed to keep them from venturing out of their sanctuary into the outside world as much as possible. It is not merely a matter of gluttony; it is about stockpiling supplies for an emotional shelter.

The True Nature of "Japan Loss"

When Americans visit Japan, they gradually break free from the realm of infinite Euclidean calculations and settle into a low-stress world governed entirely by simple Pythagorean arithmetic. Then, just before they leave, the realization hits them: they must return to that world of endless Euclidean calculations—and face the massive cognitive load that entails for their brain's "CPU." That is the source of "Japan Loss."

Consider the videos posted by overseas streamers visiting Japan: the high-energy opening reminiscent of a late-night infomercial; the gradual process of settling in; and that final, whispered "I don't wanna leave" from their hotel room or airplane seat. It isn't just because they had a good time. That sentiment is a truly poignant, heartfelt cry of distress.

Structural Differences Between American and Japanese Horror Movies

American horror films almost invariably begin within the realm of the familiar—"within arm's reach"—only to have that world suddenly shattered. Even those exaggerated screams, which might strike Japanese viewers as comical, are truly cries of the soul born of the terror that comes when one's emotional sanctuary is destroyed and one is forcibly thrust back into the high-load realm of infinite Euclidean calculations. That sheer volume of voice may well be essential for asserting one's self within that world; without it, one risks simply vanishing into that terrifying void.

In contrast, Japanese horror films often feature a gradual erosion of everyday life. Set in a "low-load" world governed by simple, predictable logic, the horror strikes from unseen blind spots—or manifests as a terror that eludes visual perception entirely. This creates a "high-load" cognitive loop: the unsettling paradox of something being present when it shouldn't be, or absent when it ought to be. Consequently, it is not only the Japanese who experience this dread—a form of intense psychological strain—but audiences of all backgrounds.

Why Americans Find Japanese Horror Scarier

American horror movies almost invariably conclude by restoring a sense of safety—bringing the viewer back to a world within arm's reach. One can return from the realm of terror to everyday life. Japanese horror, however, is different. It never returns to that space within arm's reach; indeed, there is no going back. When the film ends and you glance at your bed, you are seized by the illusion that the horror is still lurking in that very space—that zone which should have been safely within arm's reach. Japanese horror films strip them of that sense of safety within arm's reach. That is precisely why they find it so terrifying.

Original Japanese text

人間は心理的距離をピタゴラスの定理で計算しており、心理的負荷はその計算量に比例する。

　この前提を用いることで、様々な分野で語られる疑問を解消する、という推論が成り立つ。
　この推論を進めるにあたり、心理的距離を測る計算モデルを下記の様に定義する。

ピタゴラス計算＝ピタゴラスの定理で求められる「原点からの距離」を測るシンプルな計算
ユークリッド計算＝ピタゴラス計算を複数回実行して「複数座標間の距離」を測る負荷の高い計算

アメリカ的な客観視の世界: 無数の他者とのユークリッド距離を計算する社会。; この視点では広い空間から自己を見つけ出す必要があるため、リソースを消費してでも強く自己を主張する必要がある。そうしなければ文字通り世界から自分を見失ってしまう。
日本的な主観視の世界: 自己を原点とするためピタゴラス計算のみで計算できる社会。; この視点では自己は常に原点として確立されているため、ことさら自己を主張する必要がない。結果として周囲を気遣う余裕（おもてなしの心）が生まれる。

この違いが以下の疑問を解き明かす鍵となる。

日本人の空気を読む能力

　日本人は自身を中心とした極狭い範囲だけを計算すればよいので高速低負荷に心理的距離を計算できる。ゆえに空気を読む能力が高い。
　対してアメリカ人は無数のユークリッド計算の世界で「空気って何！？どこにあるの！？」とオーバーフローを起こす。日本人の空気を読む力がまるで超能力のように感じられ、理解が追いつかない。

Within arm's reachという聖域

　アメリカ人は Within arm's reach、手の届く範囲を自身の聖域（Personal Bubble）として捉える精神モデルがある。この聖域においてアメリカ人は無数のユークリッド計算世界から解放される。脳というCPUがアイドリングできる貴重な時間である。
　アメリカ人がデカい食べ物を好むのは、この聖域からできるだけ外の世界に出ないための脳の防衛本能だと言える。ただ食いしん坊なのではない。心のシェルターの備蓄なのである。

日本ロスの正体

　アメリカ人は日本に来ると無限のユークリッド計算の世界から徐々に解放され、ピタゴラス計算だけで完結する低負荷な世界へとなじんでいく。そして帰る直前になって気付いてしまう。自分がまた無数のユークリッド計算の世界へ戻らなくてはならない事に。その結果訪れる脳というCPUの負荷の大きさに。ゆえに日本ロスになる。
　海外ストリーマーによる日本来訪動画。冒頭のまるで深夜通販番組のようなテンション、徐々に日本に馴染んでいく様子、最後の日にホテルや飛行機で洩らす「帰りたくない」という一言。楽しかったからだけではない。あれは切実に悲痛な叫びなのだ。

日米のホラー映画の構造の違い

　アメリカのホラー映画は必ずと言ってよいほどWithin arm's reachから始まる。そして突然その世界を壊される。日本人にとっては滑稽にすら感じるあの大げさな叫びも、心のシェルターを破壊され、無数のユークリッド計算世界へ強制的に戻された恐怖からくるまさしく魂の叫びなのだ。そして声の大きさもまたその世界で自己を確立するために必要なのではないだろうか。そうしなければこの恐怖世界で消えてしまうから。
　日本のホラー映画は日常がじわじわ侵食される系が多い。ピタゴラス計算だけで計算可能な低負荷な世界で、見えない死角から襲ってくる恐怖、見ても視覚に映らない恐怖。そこには居るはずなのに居ない、居ないはずなのに居るという高負荷の計算ループが発生する。ゆえに日本人に限らず様々な人種が恐怖（心理的負荷）を感じる。

アメリカ人が日本のホラーをより怖がる理由

　アメリカのホラー映画は必ずと言っていいほど最後にWithin arm's reachを取り戻して終わる。恐怖の世界から日常に戻ってこれる。しかし日本のホラーは違う。決してWithin arm's reachには戻らない。戻れない。映画が終わり、ふとベッドを見るとWithin arm's reachだったはずのその空間に、まだ恐怖が潜んでいるような錯覚に襲われる。彼らは日本のホラー映画によってWithin arm's reachを失ってしまう。ゆえに、恐怖するのである。