Go Package Exports: Building Reusable Components

In Go, packages are the primary mechanism for organizing code and promoting reusability. A crucial aspect of package design is controlling which parts of your code are accessible from outside the package. This challenge focuses on understanding and implementing exported names in Go, a fundamental concept for building well-defined and maintainable libraries.

Problem Description

Your task is to create a small Go package that exposes specific functionalities to other Go programs. You will need to define variables, constants, and functions within this package, and then ensure that only the intended elements are accessible and usable by external code. This involves understanding the naming conventions that determine exportability in Go.

Key Requirements:

1. Create a Go package: This package should reside in its own directory and be importable by other Go programs.
2. Define exported and unexported elements:
   • Define at least one exported variable.
   • Define at least one exported constant.
   • Define at least one exported function.
   • Define at least one unexported variable (not accessible from outside).
   • Define at least one unexported function (not callable from outside).
3. Demonstrate exportability: Create a separate Go program (a main package) that imports your custom package and attempts to use its exported elements. This main program should also attempt to access an unexported element to verify that it is indeed inaccessible.

Expected Behavior:

• The main program should successfully access and utilize the exported variable, constant, and function from your package.
• The main program should fail to compile if it attempts to access an unexported variable or call an unexported function from your package.

Examples

Let's assume your custom package is named myutils and is located at github.com/yourusername/myutils.

Example 1: Successful Usage of Exported Elements

myutils/utils.go (Your package)

package myutils

var exportedVar string = "Hello from exported variable!"
const exportedConst int = 42

func ExportedAdd(a, b int) int {
    return a + b
}

var unexportedVar string = "This is private"

func unexportedInternalFunc() string {
    return "Internal logic"
}

main.go (The program using your package)

package main

import (
    "fmt"
    "github.com/yourusername/myutils" // Assuming your package path
)

func main() {
    fmt.Println(myutils.exportedVar)
    fmt.Println(myutils.exportedConst)
    result := myutils.ExportedAdd(5, 7)
    fmt.Println("Sum:", result)

    // The following lines would cause compile-time errors:
    // fmt.Println(myutils.unexportedVar)
    // fmt.Println(myutils.unexportedInternalFunc())
}

Output (if compiled and run successfully, excluding commented lines):

Hello from exported variable!
42
Sum: 12

Explanation: The main package successfully imports myutils and uses exportedVar, exportedConst, and ExportedAdd because their names start with an uppercase letter. Attempts to access unexportedVar or call unexportedInternalFunc would result in compile-time errors, as their names start with a lowercase letter, indicating they are private to the myutils package.

Constraints

• Your custom package must have at least one exported variable, one exported constant, and one exported function.
• Your custom package must also have at least one unexported variable and one unexported function.
• The main package must demonstrate the successful usage of exported elements and highlight the inaccessibility of unexported elements through attempted access (which will cause compile-time errors).
• The code should be valid Go 1.18 or later.

Notes

• In Go, the convention for exporting (making public) a name (variable, constant, type, function, method) is to start its identifier with an uppercase letter. Names starting with a lowercase letter are considered unexported (private) to their package.
• Think about how you would organize your package files. A single .go file per package is sufficient for this challenge, but for larger projects, you might split functionalities across multiple files within the same package directory.
• When creating your custom package, ensure it has a unique import path that you can use in your main program. For local development, you can use relative paths or set up a local module. For this exercise, github.com/yourusername/myutils is a placeholder; adapt it to your actual setup.