Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Docs] Carefully define the terms "object" and "value" #1638

Open
nmsmith opened this issue Jan 19, 2024 · 1 comment
Open

[Docs] Carefully define the terms "object" and "value" #1638

nmsmith opened this issue Jan 19, 2024 · 1 comment
Labels
mojo-docs mojo-repo Tag all issues with this label

Comments

@nmsmith
Copy link
Contributor

nmsmith commented Jan 19, 2024

Where is the problem?

https://docs.modular.com/mojo

What can we do better?

Mojo has a data model that is very different to Python. Accordingly, the meaning of the terms "object" and "value" need to be reconsidered and potentially redefined, such that they make sense in the context of Mojo's data model.

Current usage of these terms

The Python community doesn't use the term "value" consistently. It is typically used to refer to one of the following things:

  • The current state of an object.
  • The data currently stored in a variable or field.

The Mojo docs mostly adhere to the latter definition of "value", whereas "object" hasn't really been defined. I don't think "object" should be defined as a synonym for "class instance", because Mojo struct instances exhibit object-like behavior such as construction and destruction, polymorphism (via traits), etc.

In C++, the notions of {struct instance, variable, object} are basically synonymous, but the same is not true in Mojo. This is a consequence of the fact that in Mojo, the contents of a variable can be destroyed (__del__) and (re)initialized (__init__/__copyinit__) multiple times over the variable's lifetime. Thus in Mojo, it seems fair to say that a variable can hold multiple "objects" over its lifetime, similar to how a Python variable can refer to multiple objects over its lifetime.

Next steps

Mojo's data model is still being fleshed out, so perhaps it's too early to attempt to define "object" and "value". However, I believe that it is crucial to define these terms in the near future, so that the Mojo community has a precise lexicon that they can use to discuss and teach Mojo.

A precise lexicon is especially important for people new to programming, because terms such as "object" and "value" are entirely foreign to this demographic, and therefore they can't just gloss over the meaning. In my experience as a teacher, vague and inconsistent terminology is especially painful for beginners. (We've all had past experience with bad teachers who don't actually understand the concept that they are attempting to teach their students. Vague and/or inconsistent definitions are a bad teacher's forte. Let's not give these teachers the ammunition they need 😅.)

@nmsmith nmsmith added the documentation Improvements or additions to documentation label Jan 19, 2024
@nmsmith
Copy link
Contributor Author

nmsmith commented Jan 27, 2024

Given that Mojo types can be stored in variables and passed to functions, they could reasonably be considered "values". Thus, perhaps a suitable distinction would be the following:

  • An object is an instance of a type, i.e. an instance of a class or a struct.
  • A value is anything that can be stored in a variable, or passed to a function. This includes objects, types, and (perhaps some day) traits.

In other words, perhaps the term "object" can be used in contrast to "type". Said another way: every "value" is either an object, a type, or a trait, but never a combination of those things.

Technically this isn't a perfect distinction, because Python objects and classes aren't stratified into separate universes. That said, I believe Mojo structs and struct instances are stratified.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
mojo-docs mojo-repo Tag all issues with this label
Projects
None yet
Development

No branches or pull requests

2 participants