Shoggoth
kiwifarms.net
- Joined
- Aug 9, 2019
"implementation detail", which means depending on the semantics and performance profile the language designer wants to provide, these can be done in several ways. Again, I'd invite you to look at how Clojure implemented transient collections. The TLDR is that when you build collections with HAMTs, as long as you do more than two modifications you're better off using a transient.What happens when you call toTransient? Does it create a new object to wrap the original or does it internally cast the original's reference? Having to create an entirely separate object just to represent a subset of the original's functionality seems a bit daft, and if it's the latter how is it any different?
Why is is daft to create a contained "disaster area" where mutability is assumed under a subset of limiting conditions? I'd say it's actually better than being permissive with it.
The age old tension between representation and implementation. We should program to interfaces and semantics. We need to program to memory when we talk with memory. To quote Knuth, 97% of the time it doesn't matter. For the rest, either use some hardware aware language like C, or write a very clever compiler like Rust and cut your dick off.Computers have no notion of type, rather objects —pieces of memory— are granted structure by the operations performed on them. We say that an object has a type in order to constrain and guide the set of operations that are allowed on it so as to stay consistent with it's structure. But with a more abstract concept of type we cease talking about structure and begin talking about interface and semantics, why though, should we lose this fundamental flexibility by presuming that an object has *a* type?
So you want structs to be "untyped"? I'm sorry but I don't see how witnesses don't solve this problem in a static world where types are more than a gentlemanly agreement of "we read the bytes this way" I don't think I fully get what you're aiming at here, will let you know when the penny drops.I would propose that type is found in the reference, not the object. When you cast an object reference you merely view the object by a new interface, and yet such a system is still statically typed. This enables wrapping types without type wrappers, and it enables dynamically extending object functionality without changing object type. Witnesses solve half this problem, but they also have the effect of globally linking the interface to the "base type", which is not always ideal.
No wonder no one wants to program in C#, it's less readable than Javapoo