[IMPORTANT] Seriously evaluate the need for classDescriptor to parametize generically off of FieldDesriptor

There's a heavy piece of increased complexity caused by this design choice. Is this really the right way?

I know we discussed it in general, but now that I'm working with this more, I'm less convinced. Especially insofar as we have to do some janky reflection shenanigans to marshal field/class descriptors.

Please evaluate if the complexity is necessary at the simpl level or if you can accomplish the same things at the mmd/big semantics level... Thanks. Ideally, if there were other scenarios that this would make sense for other developers, that'd more easily convince me that it's worth the complexity costs.

@quyin @andruidk

So, I'm refactoring/reimplementing the class descriptor / field descriptor creation flows... as well as moving towards a slightly different flow for handling / working with field descriptors.
(In general: I want to push all of the mutability to the FD implementation, and require consumers to use FDs via an interface so it has a semblance of immutability... or, otherwise: "Mutability if you should be changing, but immutability all of the other times of the day without casting") I've also changed the general structure of how class descriptors that we don't have are handled (moved towards a callback model... it's working REALLY nicely.)

This is a high priority question... what are your thoughts, @quyin?

Hullo, @quyin ? ? ? ?

[quyin]

So you mean you will have an interface (say, IFieldDescriptor) and it will be immutable (no settings etc). All the mutable methods will be in the implementations of IFieldDescriptor. Is that correct?

That looks correct to me. Some factory classes/methods for IFieldDescriptor seems helpful.

With factories, the generics on ClassDescriptor can probably be removed safely. When you need a specific implementation of IFieldDescriptor, you can just feed a specific factory method implementation there.

So, yes, this is true. I just wanted to clarify why we needed the MMDClass / Field Descriptors. What are different about them vs standard field descirptors?

Will their by compatible with the current interfaces / strategies for creating descriptors?

[quyin]

they hold corresponding MetaMetadata / MetaMetadataField objects. this
information is passed to simpl deserializers when deserializing metadata,
because we need to maintain the connections between metadata and
meta-metadata.

we'll have to do casting at some places if we use the new non-generic
ClassDescriptors, but I think by careful design this need can be minimized.

Best Regards,
Yin Qu (屈垠)

On Mon, Feb 18, 2013 at 8:16 PM, Tom White notifications@github.com wrote:

So, yes, this is true. I just wanted to clarify why we needed the MMDClass
/ Field Descriptors. What are different about them vs standard field
descirptors?

Will their by compatible with the current interfaces / strategies for
creating descriptors?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/55#issuecomment-13753479.