In V6, there is the concept of "Core Entities", which more accurately reflect Discord's API surface, and do not abstract away the notion of empty/optional fields. This is useful for some scenarios, but is unfortunately data that's coalesced into null, transforming Optional<T> (and subsequently Optional<T?>, which have different semantics, but I digress) into T?.
This simpler API surface makes the library easier for the majority of end-users, lowering the barrier to entry, but can abstract away critical information that's needed sparsely, and may not warrant ripping away the entire curtain of the library's abstraction.
For this, I propose a new API method for entities, be it on the entity itself, or as some static helper method. The signature would look something like this:
public static bool IsEmpty<TEntity, TProperty>(this TEntity entity, Expression<Func<TEntity, TProperty>> memberAccess)
{
ArgumentNullException.ThrowIfNull(entity);
if (memberAccess.Type is not ExpressionType.MemberAccess)
{
ThrowHelper.NonMemberAccessExpression(memberAccess);
}
// Look into entity's base data and extract `Optional<TProperty>`
return !baseProperty.HasValue;
}
This is very useful for situations such as on GUILD_CREATE, where it is possible to distinguish whether a guild is "new" (added to the guild) or not (pre-existing prior to gateway connection) by checking if unavailable is false or empty.
Under normal circumstances, this would be coalesced to null, however this may not always be the case.
Of course, the actual implementation of such an API would still need to be constructed, to which I can offer to help, or even write a proof-of-concept if need be.
This was inspired by an offhand remark I made here.
In V6, there is the concept of "Core Entities", which more accurately reflect Discord's API surface, and do not abstract away the notion of empty/optional fields. This is useful for some scenarios, but is unfortunately data that's coalesced into null, transforming Optional<T> (and subsequently Optional<T?>, which have different semantics, but I digress) into T?.
This simpler API surface makes the library easier for the majority of end-users, lowering the barrier to entry, but can abstract away critical information that's needed sparsely, and may not warrant ripping away the entire curtain of the library's abstraction.
For this, I propose a new API method for entities, be it on the entity itself, or as some static helper method. The signature would look something like this:
This is very useful for situations such as on GUILD_CREATE, where it is possible to distinguish whether a guild is "new" (added to the guild) or not (pre-existing prior to gateway connection) by checking if unavailable is false or empty.
Under normal circumstances, this would be coalesced to null, however this may not always be the case.
Of course, the actual implementation of such an API would still need to be constructed, to which I can offer to help, or even write a proof-of-concept if need be.
This was inspired by an offhand remark I made here.