In this video i talk about Reference Objects.
Here are the chapters and sub chapters of this video:
Video link: https://youtu.be/kkSAVKKIoVc
I really don't like when people talk about "Reference Objects" in any form of documentation, as that term makes no real sense. It may be OK in IRC talk to use the terms "value object" vs "ref object" to explain the difference to beginners, but it is not nice there also.
Do we talk ever about "Pointer Objects"? Not that often I think. But of course we could.
The fact is, that Nim like many other programming languages has Pointers and References. We can regard References as managed pointers.
And Nim has data types, like plain numbers, or Objects and container types like Arrays or sequences.
We can access instances of data types by just using their name -- in that case the instance is generally just allocated on the stack. Or we can access instances indirectly by using the name of pointers or references, where the pointers and references itself are generally allocated on the stack.
I think Araq generally gets this right in the manual and in the official tutorials, so we should also care a bit more for using correct terms when creating second hand docs.
Maybe a few other points to your video:
You say that references are useful when data are shared, you gave an example for the case where two objects both have a ref to another object. That is fine, but for beginners a larger, real world example would be nice. I think when I was a kid data sharing would have made not much sense for me without a more detailed use case.
The other point is, that you said that for references we do not need the var keyword when passing data to procs -- we can modify the fields of object passed as references always. Well, beginners may be confused: Is the most significant advantage of references that we don't have to type that var keyword in the proc signature? So why not always us references as done in Java and Python, so that we never would have to use a var parameter. And related question: When we have a ref parameter, how can we avoid that fields can be modified?
Then you were talking about scopes and locality. That was a bit off topic, but I know why you did.
Next point: You assigned nil to a ref and show that accessing thet values would give a runtime error then. OK, but if I remember correctly you say then that it is because the GC has freed the object. That is not really correct, as the default refc GC may free objects with delay. When you assign nil to a ref, then trying to access the old value would fail, but the object may be still somewhere in memory, until GC really frees it.
And finally for ORC: First that does not really belong into this video, maybe make a own video for ARC, ORC, move semantic, cursor annotation and all that? And, when you want to advertize Nim, it is always a good idea to call ARC not a GarbageCollector, but call it Rust like deterministic memory management. Some people really like that term better than GC. Yes I know ORC is in between, that is why I generally talk about ARC only, most software should work with ARC fine.
I do know about ARC not being a GC and ORC being somewhat of a GC, i said at one point in the video that Nim has a multi-paradim memory model for those that despise GCs, though i should of said that at the beginning, BUT in order to try to sugar coat the hybrid GC, i would have to go to the very first video i made on Nim and change that one. Noone had a problem with how i did that video back then, maybe now more so but it's the first video of the series, atm i can't really afford to redo the video as i will lose those views and that video represents a large portion of my views in total and monthly.
On the ARC/ORC part, i did only briefly mention it even though it didn't exactly make sense to be in the video, i did it because it's significant without making a very short video saying "Hey ORC is awesome, use it!".
On the "You assigned nil to a ref and show that accessing thet values would give a runtime error then. OK, but if I remember correctly you say then that it is because the GC has freed the object. That is not really correct, as the default refc GC may free objects with delay. When you assign nil to a ref, then trying to access the old value would fail, but the object may be still somewhere in memory, until GC really frees it." Well i couldn't think of any better way of showing what will happen once the ref object is freed at the time, but to a beginner to Nim or programming it should suffice. You really don't want to go into to much details when trying to teach programming to a beginner, it really puts them off. I know from my experience learning on my own via YT videos, books, in school and from classmates that you REALLY should not go into technicalities any more than absolutely necessary, because they will get confused, won't know what you are talking about and lose interest. That was my reasoning to do it that way, even if it's technically not true.
"The other point is, that you said that for references we do not need the var keyword when passing data to procs -- we can modify the fields of object passed as references always. Well, beginners may be confused: Is the most significant advantage of references that we don't have to type that var keyword in the proc signature? So why not always us references as done in Java and Python, so that we never would have to use a var parameter. " For this point, i did say at the beginning i believe and at the Reference Object Use Cases chapter to use "normal/plain/non-reference objects" the vast majority of times/as much as possible, to only use ref objects when you need "shared ownership".
I guess i could of made a better example showing "Shared Ownership" though.
The subject of this particular video was not exactly enjoyable to work with, i am far more looking forward to start with Metaprogramming as that is very exciting for me, BUT i can't jump to that yet, not even close, well Generics i can, templates kind of, basic templates are very simple, macros... no.
At some point i will have to redo many of the videos i have made, because some have bad audio, no zoom when required(horrible on phones), will get out dated probably, could of been done better.
You get a shortcut regardless..
let x = (ref Foo)(a: ...)
The other point is, that you said that for references we do not need the var keyword when passing data to procs -- we can modify the fields of object passed as references always. Well, beginners may be confused: Is the most significant advantage of references that we don't have to type that var keyword in the procedure signature? So why not always us references as done in Java and Python, so that we never would have to use a var parameter.
That's a good question that always bother me. The only justification I found for keeping var parameters is that you can't call the proc that defines them with nil or constant values. So you provide a stricter API contract than declaring them with ref.
This disregards any of the semantic differences between pointer objects and value objects. Plus if you want an api that changes where a reference points you still need var parameters. The reason you use value types instead of reference types is that you want their semantics. There is more to objects vs pointers than "you do not use var".
A few traits of references/pointers are:
Compared to objects traits:
Atleast in my view you decide from the above(and any other traits I missed) which to use, since there are reason to prefer one to the other. It's not just about a few language semantics it's about how the types are used/program is written.
I know from my experience learning on my own via YT videos, books, in school and from classmates that you REALLY should not go into technicalities any more than absolutely necessary, because they will get confused, won't know what you are talking about and lose interest. That was my reasoning to do it that way, even if it's technically not true.
Yeah, you often need these little "lies" to get the point accross and than later these points can be refined further.
“Another noteworthy characteristic of this manual is that it doesn’t always tell the truth. When certain concepts of TeX are introduced informally, general rules will be stated; afterwards you will find that the rules aren’t strictly true…. The author feels that this technique of deliberate lying will actually make it easier for you to learn the ideas. Once you understand a simple but false rule, it will not be hard to supplement that rule with its exceptions.” — Donald Knuth, The TeX Book.
Cited in The Dangers of deep knowledge: https://medium.com/@practicingdev/the-dangers-of-deep-knowledge-3043520441eb