Clean up User Defined Types Chapter

[BryanNilsen]

for Andy:
https://github.com/nashville-software-school/bangazon-inc/blob/master/book-1-orientation/chapters/CLASSES_INTRO.md

confusing part about the namespace in the Urban Planner exercise.

[copypastedeveloper]

in the same vein, I would rather the area about types use the word object less, since not all types are objects. enums, structs, interfaces, value types, etc are not technically objects (or technically instantiated for that matter) unless they've been boxed. I think the day class spends less time on the distinction between value and reference types as well, which is another time when the meaning of the word object matters. feels pedantic, but language is one of the main things we've got to make sure we're all using the same as developers, especially within a given language context.

[askingalot]

The only time I talk at all about value vs reference types is toward the end of the course when I'm helping students with interview prep. We don't talk about enums or structs at all (well structs might come up incidentally when I talk about DateTime as a value type).

IMHO not too many students are ready to think about value vs reference semantics or stack vs heap allocated memory. I could be convinced that they can understand enums, but it also hasn't seen necessary to introduce them.

Do you feel that we should only use the word "object" to refer to heap allocated obj^H^H^H...things?

[copypastedeveloper]

We don't talk about structs but all the other things we talk about. We do also talk and discuss extensively stack vs heap and reference vs value type and the memory allocation implications. They all get it, and even talk about how it explains a lot of problems they had when destructuring in JavaScript and not considering the reference implications. The difference between value and reference types is so fundamental, I can't imagine not talking about it. @franticallycodes thoughts?

[askingalot]

I see. I actually do talk about reference semantics. (not the ref keyword, but how reference types work). What I don't talk about is value semantics. I think it doesn't come up because all the value types we use are immutable, so you don't notice the copy behavior.

[franticallycodes]

Yeah, we don't mention the ref keyword cause it's just wrong 😉 and the stack vs heap stuff may not actually stick with most students. Enums are weird to parse and lose some usefulness once we head toward database stuff, but they tie nicely into taking about default values which I think is the second most important reason to talk about reference vs value types. The most important being that it's too easy to accidentally mutate a reference type. At least 1 or 2 students in every class ends up with a bug due to this and it's nice to explain that bug through the lens of something they've already heard about.

[AdamSheaffer]

At least 1 or 2 students in every class ends up with a bug due to this and it's nice to explain that bug through the lens of something they've already heard about.

I can buy that. Have you talked with Zoe about this same thing? I'm sure this has bit them on their JS projects as well. Do you think this a topic that needs to be covered early on? I could definitely see this being helpful info when thinking about react state

[copypastedeveloper]

I think its useful, but i also think its a hard concept to do in the beginning, you could maybe show the mechanics behind references pretty easily in react, and we have talked a little with zoe about destructuring and reference types in particular, or i believe adam w. has anyway. i think the discussion of memory and stack vs heap is probably best left until later, but that's just me.

[stevebrownlee]

I love this conversation, so I'll throw in my 2 cents.

Value/reference comprehension is akin to an experiment I've been running since cohort 15, which is trying to teach some of the SOLID principles. With plenty of experiments and different ways of trying to explain it and have them write code that follows the principles, there's only so much their brains' neurons can be rewired in 120 days of practice.

In that short amount of time, they are still struggling with building mental models for simplistic modular applications, and still trying to remember basic data structures and syntax. Without that strong foundation solidified, we can't build any fancy structures on top of it. Near the end of 6 months, there will be a small amount of students who came in with their neurons wired more efficiently than others and may be able to understand value/ref theory.

It is entirely more likely that the extra time that evening students spend on practice and reflection allows their brains to grow enough to be able to understand concepts that day student aren't ready to yet.

Having said all that, I'll conclude with my opinion that value/ref comprehension is not a core learning objective of NSS. I have yet to hear feedback from a community member/employer that it's valuable knowledge that they expect a student to have. That doesn't mean we avoid discussing it or make references to it as we coach them down their paths, but the original intent of this ticket needs to be brought back into the light.

Considering it's the original reference chapter that they read, and we try to discuss, making sure the vocabulary is correct is very important, but diving into any details about value/ref types won't have any return on investment.

So what about this chapter is...

1. Flat out incorrect and should be changed immediately
2. Misleading or vague and should be clarified