On Jun 5, 2013, at 11:29 AM, Jb Evain <[email protected]> wrote: > Having a quick look at the issue, a third possibility would be to add a new > property to the ReaderParameters specifying that the symbol files are > "optional". > > That would fix 1. as you are in control of the ReaderParameters, and 2. > > I'm still trying to come up with a good name though.
RequireSymbols? That doesn't quite address _implementation_, as mentioned in (2). ISymbolReaderProvider.GetSymbolReader() doesn't have access to the ReaderParameters instance, and thus can't change behavior based on them. AssemblyReader.ReadSymbols() can access the ReaderParameters, but that's where my semantic change comes in: how does AssemblyReader.ReadSymbols() and ISymbolReaderProvider.GetSymbolReader() interract? Via exceptions? Via null return value? Something else? There's ~no documentation here, so either are plausible, but at the same time either could break existing ISymbolReaderProvider implementations. How stable is the API? We could just change the ISymbolReaderProvider.GetSymbolReader() methods to take a ReaderParameters parameter. This would also break compatibility, but might allow the implementation to be more intelligent...or make implementing them more complicated. - Jon -- -- -- mono-cecil --- You received this message because you are subscribed to the Google Groups "mono-cecil" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
