Extension methods work if you're not planning on adding fields - but it
means you can't add properties either, of course.
I certainly intend people to be able to use partial classes - that's why
they're generated as partial. As mentioned, maybe I should just remove the
attribute...
Jon
On Monday, 26 October 2015 17:48:01 UTC+2, Rob Cecil wrote:
>
> Not off hand. I was also thinking this morning that extension classes
> could be used, if you were NOT planning on supporting extension through
> partial definitions. Almost as good.
>
> Rob
>
> On Sunday, October 25, 2015 at 11:24:25 AM UTC-4, Jon Skeet wrote:
>>
>> Hmm. Good question. I had certainly intended for these classes to be
>> "expanded" using partial classes (as I've done for some of the well-known
>> types, for example).
>>
>> It's possible that we should just remove the attribute from the class
>> declaration, possibly adding either this attribute or others to individual
>> properties etc. Do you have any particular views on which attributes you
>> *would* like to be applied where?
>>
>> Jon
>>
>> On Friday, 23 October 2015 21:53:32 UTC+1, Rob Cecil wrote:
>>>
>>> I noticed that the typical protobuf class looks like::
>>>
>>> public sealed partial class OpenViewRequest : pb::IMessage<
>>> OpenViewRequest> {
>>>
>>>
>>>
>>> Which rules out derived classes, but not partials. However, the whole
>>> class is decorated with DebuggerNonUserCode, which interferes with
>>> debugging my partial definition.
>>>
>>> Should I avoid this?
>>>
>>> I'm just defining additional ctors that take data classes.
>>>
>>> Thanks
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.
