Better syntax for private constants

Open
#9 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
ruby
Domain
tooling

Research direction

Start by examining Ruby's existing constant visibility behavior and the proposed private_constants entry point in the issue. Compare the scoped-block proposal with the current private_constant API; done means the project has an agreed syntax and behavior for marking constants defined in the scope as private.

Written by the indexing model from the issue text.

Description

good first issue

Constants are a bit of an odd ball. They don't respect the usual public/protected/private regions like methods do:

class C
  private

  SECRET = 123 # Not actually private!
end

This would need a separate private_constant :SECRET call.

Method def expressions evaluate to the name of the method that was defined, making this possible:

private def method; end

By comparison, constant definitions evaluate to their right hand side, so you can't just do this:

private_constant SECRET = 123 # TypeError: 123 is not a symbol nor a string

The clunky syntax of repeating the constant name every time you want to make it private, means that people don't actually do it in practice. Perhaps we can provide a better syntax for private constants?

Possible solution

Shopify's internal dev tool has a solution for this, using a scoped block, in which all constant definitions are made public. Example usage:

private_constants do
  SECRET = 123
  ANOTHER_CONST = 456
end

Possible implementation

# Mark all constants defined within the block as private
#: { -> void } -> void
def private_constants(&block)
  before = constants(false)
  yield
  private_constant(*(constants(false) - before))
end
Dominant language
Ruby
Stars
3
Forks
5
Avg merge
8d 23h
Merged PRs (30d)
8

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Shopify/type_toolkit

All issues in Shopify/type_toolkit

Similar issues

More Ruby issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.