Go Packages: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 34: Line 34:


=Consuming Packages=
=Consuming Packages=
=TO DO=
* https://medium.com/rungo/everything-you-need-to-know-about-packages-in-go-b8bac62b74cc

Revision as of 00:52, 7 September 2023

Internal

Overview

Go modularization is build upon the concept of package.

A Go package is a collection of variables, functions and type definitions, such as structs, and interfaces that are inter-related and provide coherent, unified functionality. The intention behind bundling together such features into package is to make the design and the maintenance of large programs practical. Packages are units that can be easier understood and changed, and that can also evolve independently of other packages. These characteristics allow packages to be shared, distributed and reused by different and otherwise independent projects.

Packages provide a namespace for their members.

They also provide an encapsulation mechanism for their code, by hiding implementation details and only exposing features, such as variables, types or functions that are meant to be publicly consumed.

Package are declared by writing one or more source files annotated with the same package name, and are consumed by other packages by importing them with the import keyword.

Packages as Namespaces

Each package defines a distinct namespace that hosts all its identifiers. Within the package namespace, all identifiers must be unique.

When a public feature of a package, such as a function or a type is used outside of the package, its name must prefixed with the name of the package, with the intention of making the package and feature name pair unique in the universe block. Such a name is referred to as qualified identifier. For example, the Println() function, exported by the fmt package, is invoked with the fmt.Println qualified identifier:

import "fmt"
...
fmt.Println("hello")

This mechanism allows us to chose short, clear names for the members of a package, without creating conflicts with other parts of the program.

Packages as Encapsulation Mechanism

Packages control which names are visible outside the package, by a simple convention: the names that start with an uppercase letter are publicly visible, those that start with a lowercase letter are not. Publicly visible names are referred to as exported names.

Encapsulation is useful because it allows the package maintainer to change the implementation of the hidden members without affecting the public interface of the package, thus allowing the package to evolve without breaking its dependents. Restricting variables' visibility constrains the package clients to access and update them only through exported functions that preserve internal invariants and enforce mutual exclusion in concurrent programs.

Declaring Packages

Publishing Packages

When a package file changes, the entire package must be recompiled and all the packages that depend on it.

Consuming Packages