You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In general, the idea is to add extensions with nullable values for Possibly* types.
For example, it would be nice to write val user: User? = message.user instead of val user: User? = message.asFromUser().user.
When there will be a subtype with user member in a code, the extension will be just ignored.
There is an another way, to make this without extensions, just using member functions/properties. It may be better since the highlighting works faster for member functions. And they do not require imports.
So the functions like as... may become less useful and may be even removed in the future.
This allows users to use two patterns for this cases: fast access to nullable properties whenever the user needs it, and the old good one way - strong types with not null properties.
I saw that the unability to use the first way leads newbies to migrate to libraries like kotlin-telegram-bot where this way is the only one available, but when theirs bots become a bit complex, they have to migrate again to this lib in case they want to avoid nulls.
The text was updated successfully, but these errors were encountered:
In general, the idea is to add extensions with nullable values for Possibly* types.
For example, it would be nice to write
val user: User? = message.user
instead ofval user: User? = message.asFromUser().user
.When there will be a subtype with
user
member in a code, the extension will be just ignored.There is an another way, to make this without extensions, just using member functions/properties. It may be better since the highlighting works faster for member functions. And they do not require imports.
So the functions like
as...
may become less useful and may be even removed in the future.This allows users to use two patterns for this cases: fast access to nullable properties whenever the user needs it, and the old good one way - strong types with not null properties.
I saw that the unability to use the first way leads newbies to migrate to libraries like
kotlin-telegram-bot
where this way is the only one available, but when theirs bots become a bit complex, they have to migrate again to this lib in case they want to avoid nulls.The text was updated successfully, but these errors were encountered: