Why are so many classes marked sealed

[JoeHershman]

What is the reasoning driving making what seems like almost every class in the API to be sealed?  There have already been a number of times where I could solve a problem so easily with inheritance and it is not possible requiring more complex solutions.  I just don't understand why this seems to be the default behavior.  

[dotMorten_esri]

I would love to hear about your specific scenarios where subclassing would have solved your issue. Could you elaborate?

[JoeHershman]

Our applications reads a WebMap configuration from Portal and stored that file on the client similar to some of the new functionality in the 100.1 release, although, we have requirements that unfortunately could not be solved with these new features.  On the client we also can configure a field as being required (although at a db level the field would allow null values).

What I think would be an easy and elegant solution is that when the popup definition is hydrated we use an inherited PopupField object that also includes the IsRequired property.  The PopupDefinition is already attached to the FeatureLayer so the PopupField is accessible and we can always get to that information.  Would just need to cast to the inherited type when the IsRequired property is needed.

There are also times when being able to mock up an object in unit testing could be useful. 

Thanks

-Joe

[dotMorten_esri]

Would you expect the information in this custom popup field to also get serialized when saving the map locally? (this is not something we currently allow, as we are being quite strict about only serializing data according to the webmap spec).

Modifying/replacing the popup fields will mark the webmap as edited which could have some very inconvenient side-effects. I'm wondering if there's a better and different way to accommodate for this.

Another approach might be to create an IValueConverter that binds to the popup definition/layer and converts to the IsRequired Boolean using the same logic you were using to hydrate it in the first place.

[JoeHershman]

I may not be describing things clearly.  My implementation is completely custom, in principle it is similar to the OfflineMap features in 100.1.  This was done prior, and the current approach in 100.1 does not yet meet our requirements so we are not changing to use the these features in the API.

The WebMap configuration is extracted as is from Portal and that is saved on the client.  Our implementation actually converts it to xml and keeps it in the app.config file.  This is all done with some extensions to standard json.net serialization.  While the offline replica databases are loaded into the map on the client, this serialized definition is used to hydrate the properties of the feature layers as they are created.  This includes the PopupDefintion for the FeatureLayer.  Again json.net is used to de-serialize these objects  Where we store the IsRequired is really just an implementation detail, right now it is stored separate from the WebMap configuration.

When a user wants to edit a feature class the applications uses the PopupField properties to determine if a specific field is editable.  My thinking was that if I could inherit from PopupField the IsRequired property could be added and it would be available when my collection of bound FieldItems is built out on our data entry form.  We have a solution in place, but I find it a bit clunky.

I am unclear about your suggestion.  I think I understand how IValueConverter works, but I don't know what you are suggesting when you say

binds to the popup definition/layer

Thanks.  I appreciate your taking that time to respond

-Joe