What design pattern should I use for specific multiple inheritance?
Let's say I have an interface called Squid.
And we have a bunch of different types of squids:
Here's everything a squid can be:
How would I go about create an instance of a squid? Should I go about creating 4 classes
AdvancedLandSquid like this:
I think that's called the Abstract Factory method? It seems very tedious though. Any better way of doing so?
@firefish Yeah, that's cool.. but they haven't started. Actons are worth more than words.
Could I have asked one of the people who are keen on learning it about the duplicate crate? No, because they have no clue what a crate even is, because they want to learn it, but they haven't started.
Thus we return to what I had originally said:
...so few people use it.
@DynamicSquid Whoa whoa, you need to learn the language.
Once you have, you'll realize C++ is the language without restriction and with weird rules. Rust is a language that makes sense.
Also, it has one major advantage over C++: there is no undefined behavior whatsoever.
You can have a multi-threaded program, knowing everything will always run flawlessly (okay, it might deadlock, but still).
You will never run into concurrent reading/writing problems.
You should never get a system floating-point exception.
Arithmetic should never overflow and give weird results.
You can't perform certain operations in Rust, but you can in C++:
You can't read uninitialized data:
You can't read out of bounds memory.
You get where I'm going, the list continues, you can't do a bunch of dumb stuff, do you know what that means?
Every package you import and use should work correctly, without having to review the code.
It doesn't have classes, so if you like OOP styled code, you'll have to learn how to write idiomatic Rust.
@DynamicSquid To that, I must ask you the following:
In a strongly-typed, and statically typed language, should type safety be the programmer's fault, or the language's fault?
Should you run a compiler on a text file, and get a properly working executable, or an improperly-working executable?
Should source code that was developed on a Windows computer be capable of being compiled on a Linux, and run just as it had done on the Windows, without change?
Should undefined behavior be allowed to even exist?
@xxpertHacker But again, I think the feeling of "this language won't let me do this" is harmful since it's limiting programmers in what they can do. Programming's (I'm talking about low level programming since that's obviously the best) all about working with the computer, but if you restrict some of the things you can do with the computer, well then you're not really working with the computer, if that makes any sense
@DynamicSquid We can both agree on what to choose from those questions I raised, and Rust made the right choices.
Simply think of the restrictions like you think of what you can do in C/C++ on a pointer.
Let's start, what is a pointer?
Computers only understand numbers, a pointer is a literal integer, yet... in a way, it's not.
It is an integer, yet it simply is used to load and store memory at the specific point that it "points" to.
Why do I bring this idea up at all?
Because they are an abstract idea, but they have restrictions.
Does that seem like a weird restriction? Hopefully not. Yet it makes perfect sense to restrict what can be done in some cases, yet most of the time, C++ just lets you do whatever you want, whether or not it makes sense at all.
@DynamicSquid The idea isn't restriction at all, more likely, it's explicitness.
Often times, in source code, when you see something weird, one of thee things are true:
- You stopped and said, "what am I looking at?"
- There is a comment explaining the apparent nonsense, explaining that it is not nonsense, but some weird technique.
- You actually understood what you saw, because you've seen it before, or had actually done it before.
If you've ever seen a weird piece of code before, you should agree.
The first possibility is very likely, and it exists because languages let people do weird stuff. This possibility does not exist within Rust.
The second exists for the same reason as the first and is due to a lack of language-level support for whatever they did, or because they were lazy. What if you provide language-level support for this?
The third possibility is very unlikely and doesn't need to exist, because weird code practice shouldn't need to exist.