Which of these intuitions is correct?

Your coworker is correct (assuming standard type systems).

Think about it, classes represent sets of legal values. If class A has one byte field F, you might be inclined to think that A has 256 legal values, but that intuition is incorrect. A is restricting "every permutation of values ever" to "must have field F be 0-255".

If you extend A with B which has another byte field FF, that is adding restrictions. Instead of "value where F is byte", you have "value where F is byte && FF is also byte". Since you're keeping the old rules, everything that worked for the basetype still works for your subtype. But since you're adding rules, you're further specializing away from "could be anything".

Or to think of it another way, assume that A had a bunch of subtypes: B, C, and D. A variable of type A could be any of these subtypes, but a variable of type B is more specific. It (in most type systems) cannot be a C or a D.

Is this an anti-pattern?

Enh? Having specialized objects is useful and not clearly detrimental to code. Achieving that result by using subtyping is perhaps a little questionable, but depends on what tools you have at your disposal. Even with better tools this implementation is simple, straightforward and robust.

I would not consider this an anti-pattern since it is not clearly wrong and bad in any situation.

Which of these intuitions is correct?

Your coworker is correct (assuming standard type systems).

Think about it, classes represent possible legal values. If class A has one byte field F, you might be inclined to think that A has 256 legal values, but that intuition is incorrect. A is restricting "every permutation of values ever" to "must have field F be 0-255".

If you extend A with B which has another byte field FF, that is adding restrictions. Instead of "value where F is byte", you have "value where F is byte && FF is also byte". Since you're keeping the old rules, everything that worked for the basetype still works for your subtype. But since you're adding rules, you're further specializing away from "could be anything".

Or to think of it another way, assume that A had a bunch of subtypes: B, C, and D. A variable of type A could be any of these subtypes, but a variable of type B is more specific. It (in most type systems) cannot be a C or a D.

Is this an anti-pattern?

Enh? Having specialized objects is useful and not clearly detrimental to code. Achieving that result by using subtyping is perhaps a little questionable, but depends on what tools you have at your disposal. Even with better tools this implementation is simple, straightforward and robust.

I would not consider this an anti-pattern since it is not clearly wrong and bad in any situation.

Which of these intuitions is correct?

Your coworker is correct (assuming standard type systems).

Think about it, classes represent sets of legal values. If class A has one byte field F, you might be inclined to think that A has 256 legal values, but that intuition is incorrect. A is restricting "every permutation of values ever" to "must have field F be 0-255".

If you extend A with B which has another byte field FF, that is adding restrictions. Instead of "value where F is byte", you have "value where F is byte && FF is also byte". More rules means fewer possible values, means more specific.

Is this an anti-pattern?

Enh? Having specialized objects is useful and not clearly detrimental to code. Achieving that result by using subtyping is perhaps a little questionable, but depends on what tools you have at your disposal. Even with better tools this implementation is simple, straightforward and robust.

I would not consider this an anti-pattern since it is not clearly wrong and bad in any situation.

Which of these intuitions is correct?

Your coworker is correct (assuming standard type systems).

Think about it, classes represent sets of legal values. If class A has one byte field F, you might be inclined to think that A has 256 legal values, but that intuition is incorrect. A is restricting "every permutation of values ever" to "must have field F be 0-255".

If you extend A with B which has another byte field FF, that is adding restrictions. Instead of "value where F is byte", you have "value where F is byte && FF is also byte". Since you're keeping the old rules, everything that worked for the basetype still works for your subtype. But since you're adding rules, you're further specializing away from "could be anything".

Or to think of it another way, assume that A had a bunch of subtypes: B, C, and D. A variable of type A could be any of these subtypes, but a variable of type B is more specific. It (in most type systems) cannot be a C or a D.

Is this an anti-pattern?

Enh? Having specialized objects is useful and not clearly detrimental to code. Achieving that result by using subtyping is perhaps a little questionable, but depends on what tools you have at your disposal. Even with better tools this implementation is simple, straightforward and robust.

I would not consider this an anti-pattern since it is not clearly wrong and bad in any situation.