I still don’t know how Wine works and I’m a Linux advocate.

I will never buy another Samsung phone or tablet. I was done the moment I started getting notification ads from the Samsung store that I cannot disable.

I can’t even install Rust…

This was a good blog post. I have started using approach #3 as well for just about every situation where I was originally planning on just using a enum type by itself. Inevitably I end up needing to apply shared state to all of my enums (create date, parent table ID, etc.) and this approach has really worked out very well. You can also add some convenience functions for returning if the kind is one of the variants (ex: IsKeywordSearch) to make if-statements easier to read (and a match on the type enum is overly verbose when you don’t need the properties contained within the enum itself).

# Copy pwd into clipboard using pbcopy
alias cpwd="pwd | tr -d '\n' | pbcopy && echo 'pwd copied into clipboard'"

# grep search the current directory
function lg() {
  ls -alt | grep $1
}

Can anyone explain what this means to me like I’m 5?

Exactly. The functions of the super trait are also required when implementing the child trait’s functions, as you would expect from inheritance.

Basically, you can generalize your trait types into their parent (super) traits for situations when functionality is specific to those supertrait objects.

As an example, if you have a trait CanBark and it is a super trait for the trait IsDog, you can coerce your references of &dyn IsDog into a &dyn CanBark. You can then work with other trait types that share a super trait.

trait CanBark {
    fn bark(&self);
}
trait IsSeal: CanBark { }
trait IsDog: CanBark { }

fn bark_as_group(barkers: &Vec<&dyn CanBark>) {
    for barker in barkers {
        barker.bark();
    }
}

let spot: &dyn IsDog = get_spot();
let seal: &dyn IsSeal = get_seal();
let barkers: Vec<&dyn CanBark> = Vec::new();
barkers.push(spot);  // coerced
barkers.push(seal);  // coerced
bark_as_group(&barkers);

At least, I hope this is possible now. If it’s purely “you can return a coerced type from a function”, that is less useful.

Wow, that trait feature is great. I’ve been eagerly waiting for that one for a long time. Thank you to everyone who made that possible.

Sounds good. Please share what you find and what you end up going with.

There are a few different ways to solve this problem without using unsafe and I’m not sure what would be considered idiomatic. Another option is to ultimately encapsulate all of the nodes in a reference-counted box like Rc or Arc and specify the type of your parent/child/sibling references to the same reference-counted box type. With that, you just share cloned instances around as needed.

The primary drawback here is that for mutable access you end up having to perform a lock every time on an underlying Mutex (or something similar). You also no longer have direct access to the singular instance of the node.

There are pros and cons to every approach.

One way of solving this is to structure all of your nodes into a HashMap with the node ID as the key and the node type as the value. The underlying node type could have node IDs for referencing purposes. You lose the ability to reference the parent/child/sibling directly, but you avoid direct circular dependencies. That said, now you need to manage dangling references for when the node is removed from the main HashMap collection.

deleted by creator

I hate that it came to this, after so many Rust devs left, but all I can say is “Good.”

It happened to a friend who wasn’t passing in the proper types into their stored procedures, all strings, and “null” (not case sensitive) conflicted with actual null values. Everything in the web interface were strings, and so was null.

For some people it takes this mistake before they learn to always care about the data types you’re passing in.

That’s an interesting take. I didn’t know that the tool screen even existed, so I had no idea that it would be nice to have in my toolbelt for future needs. A README also helps those that may already know a lot about screen and want to know the differences between screen and their implementation.

There is nothing better in open source than a thorough, well-written README at the root of the project. Wanting others who don’t understand the source of the inspiration to be completely clueless is unfriendly (at best).

The README helped a lot, thanks. Just wanted to point out a minor typo, I think the second word under the “Client” section is meant to be the word “client”.

deleted by creator

Thanks for the explanation and README. I’ll check it out.