[QUESTION] Is it safe to derive my type from BsonExpression?

[nightroman]

LiteDB 5.0.2

Fact: The type LiteDB.BsonExpression is not sealed.
Question: Is this "accidental" or I may "safely" derive my type from it?

I have a use case for such inheritance in Ldbc, the PowerShell module based on LiteDB.

For the moment I use a not derived wrapper of BsonExpression, somewhat more PowerShell friendly. Of course, sooner or later it is supposed to be passed in LiteDB methods expecting BsonExpression and has to be unwrapped, sometimes with expensive type checks (because my command parameters accept native BsonExpression as well).

If I derive my wrapper from BsonExpression then some tedious type checks may be removed and performance may be better. But I am not sure if this design is safe. Looking forward to some advice.

[mbdavid]

My quick answer: I never thought about in a class that inherits BsonExpression. This class is like Expression in LINQ tree. But in LINQ, types of Expression are represented using another classes. In BsonExpression I simplify this using only Type.

I have no plans (yet) to create sub/super classes from BsonExpression. I had no needs for that. BsonExpression works nice for me now. If you prefer to inherits from BsonExpression I don't see any problem..... but, I will talk with @lbnascimento and @JensSchadron about this if they have another opinion about this.

[nightroman]

It turns out it is practically impossible to derive from BsonExpression because it provides no public or protected constructors. Thus, see the PR, I suggest making BsonExpression explicitly sealed. This will avoid further similar questions and unsuccessful attempts to derive.