Karthik Nayak <karthik.188@xxxxxxxxx> writes: > If I understood Junio's comments correctly, he was drawing out the point > about if we even need the separation of options for refs. Since the only > option we're adding is a verbose: > ... > Your approach seems to take a different path though, where we create a > new route of creating two new structs, one for refs and another for > objects and adding both to fsck_objects. If we're doing this, wouldn't > it be better to use the enum+union idea, like Junio mentioned? That way > we would have clarity around which type it represents. Yup. If we are going to over-engineer this, enum+union would be a reasonable way to do so, but we should ask if we need to split (and more importantly, if we know the problem space well enough to make the right split) in the first place. Just like premature optimization is bad, premature factoring and over-modularization is bad. Thanks.
