model module part 2

[CodesInChaos]

• Adapt all internal consumers to use the types through model
• Don't re-export from value
• Turn modules into sub-modules of model

[1st1]

I'm curious why is it called "model"? As in "data model"? Why not "types"?

[CodesInChaos]

Because it's the types the application is expected to use in its data model. Just types sounded too general.

But I'm not particularly married to the name, my main goal here is to centralize all those types in one module.

[elprans]

Let's use datatypes for consistency with edgedb-python

[CodesInChaos]

You might also want to take a look at #38 and provide some feedback on naming and structure there.

Concerning datatypes, the rust naming convention of modules is snake_case, so data_types might fit better. Personally I prefer a shorter name, since this probably the most commonly used import.

[1st1]

You might also want to take a look at #38 and provide some feedback on naming and structure there.

Commented there.

[tailhook]

I also don't like data_types because of length. scalars is better (but we should move OutOfRangeError into errors then). model is also fine for me.

Other than bikeshedding on the name, looks good.

[CodesInChaos]

I don't think we should block this PR on the name bikeshedding, since it's already called model in the current master branch, this just cleans up the internal structure.

---

I don't like scalars, since that's a technical detail, the user won't care about (and some might not even know what a scalar is). What about simply data?

[tailhook]

Yes. Let's continue discussion on #46