Remove object helper functions?

[davfsa]

I have been considering this for a while and just want to get some opinions on it.

As it currently stands, (most) objects have short-hands for common functions like .get_guild or .get_channel. They are nice to have, but the problem that I am starting to see is people using them to chain calls like message.get_channel().get_guild() which can cause issues in the long run. Additionally, it takes much more effort to maintain and ensure all the objects have all the helper functions they should.

The idea is to deprecate and eventually remove all these short-hands and push people to use .cache.xxx and .rest.xxx respectively, making them more aware of what they are actually doing. (User.send would be abstracted in the REST objects to create_dm_message, where it will act in the same way, but with a documentation warning on what calling the function entails)

[parafoxia]

I feel like removing them to get rid of the chain caching problem is a good thing, though the documentation needs to be updated to make these things more known. Currently you just kinda have to stumble upon it or ask -- it would be nice if x_id attributes made a mention of how to retrieve the full objects from the cache or the rest API.

[davfsa]

Ideally a guide would be written before this is done so that it points people in the right direction

[parafoxia]

Good idea. I think that alongside the extra doc messages will probably be enough to steer people in the direction they want. I think a guide alone will be insufficient.

[Jonxslays]

I don't feel like removing a shortcut method because people use it wrong is correct.

Having it there is nice when you actually need to use it.

People have habits built up from other libraries so in order to bring them into the Hikari way of thinking, it takes time and practice to break those habits. Almost everyone who does this consistently is a Hikari beginner.

Maybe a clear explanation of the way Hikari intends for end users to interact with the API (mainly snowflakes) is in order. Even just 1 or 2 paragraphs on the first page of the docs could have an impact.

[davfsa]

It's those bad habits that can build up and expand, and not many people read the docs anyways. I have again and again seen code recommendations that consist of chaining cache calls from even "advanced" hikari users, not because they don't know their way around the lib, but because it is simpler than looking for the appropriate cache method that does it all a) in 1 call 2) much more efficiently and without creating useless objects, which is something I find very important.

I completely understand the downsides of this, thus the poll, so I appreciate the feedback a lot, just wanted to give it my personal answer. Ultimately I will take int consideration votes + comments in and out of this poll to think if I will eventually remove them or not

[GoogleGenius]

Personally, this is something I do agree with. While an API wrapper abstracting with helper methods is a nice quality of life thing, it can, if misused, end up with worse overall code. I think Hikari should really help users forward with developing good code and practices; this library is different from others and does not have to have similar design choices.

[Tmpod]

Whole heartedly agree. Hikari has always existed on the basis of being more "correct", so to speak, than its counterparts, providing good typing, modularity and other programming practices. Making the move towards just the cache and rest methods will not only further cement that goal, but, like dav said, will help maintainability and the library as a whole in the long run.

[LEv145]

The idea is pretty good, there should be only 1 obvious way to do it.

But if you leave them, it's better to make them in the form of functions that take an object, like:

shorts.get_channel_from_message(message)

This way we don't link cache/rest and objects directly