Reputation
1,864
Next tag badge:
106/100 score
1/20 answers
Badges
1 7 12
Impact
~128k people reached

  • 0 posts edited
  • 0 helpful flags
  • 44 votes cast
Jun
8
awarded  Great Answer
Apr
13
comment Under what cirumstances would type 'System.Object' qualify for serialization?
@toplel32 if your plan is to make it publicly available, then sure: shoot me an email or ping me here when you release it; I'm "more than competent" in serialization technology and techniques
Apr
13
comment Under what cirumstances would type 'System.Object' qualify for serialization?
@toplel32 actually MS has been doing more and more json - for example, the DNX ("vNext") project files are json, not xml. Re private members: IIRC, DataContractSerializer (which is xml-based) emits fields, not properties, if the type is not annotated - likewise NetDataContractSerializer. Likewise, formats that are intended to be human-readable often are not flat; unless you actually mean tree vs graph. As someone who has written fairly fully-developed serializers: good luck. But I think some of your questions are concerning for a tool approaching completion rather than conception.
Apr
13
comment Under what cirumstances would type 'System.Object' qualify for serialization?
@RobertHarvey it is incredibly brittle re refactoring and versioning, and unless you do all the work yourself (ISerializable etc) it is brittle towards internal field changes; it isn't cross-platform, and has a nasty habit of sucking in events and serializing unexpected objects. I've seen lots of people get into messes where they can't deserialize their data back via BinaryFormatter, so yes: it has some issues. protobuf-net deliberately avoids the worst of these problems; although to be fair: all serializers have scenarios they are strong at / weak at.
Apr
13
comment Under what cirumstances would type 'System.Object' qualify for serialization?
@toplel32 your comment on IList is very valid; but it gets more complicated; what patterns do you want to support? Not everything is IList<T>. It could be IEnumerable<T> with a good-looking Add. It could even not be IEnumerable<T> but have a custom GetEnumerator() type that is strongly typed. Lots of very awkward questions. Then there's dictionaries, etc. Again: why do you want to write your own? What is the feature you want to add that isn't already available?
Apr
13
comment Under what cirumstances would type 'System.Object' qualify for serialization?
@toplel32 I disagree with your description; SOAP isn't intended to be presented; XML is barely human readable in most cases. Json is more readable, but I'd say that even that says nothing about the intent.
Apr
13
answered Under what cirumstances would type 'System.Object' qualify for serialization?
Sep
13
awarded  Yearling
Sep
5
awarded  Good Answer
Aug
1
comment Should I use WCF, raw Sockets, or something else to send receive data from a command line app?
Protobuf itself doesn't define a message passing stack. You can of course pass protobuf messages as the payload :)
Aug
1
comment Should I use WCF, raw Sockets, or something else to send receive data from a command line app?
I'd be tempted to try simplsockets - but really, just about anything should work
Sep
13
awarded  Yearling
Feb
26
awarded  Caucus
Feb
21
awarded  Guru
Oct
23
answered Should I create repositories with special functions like getStaffActive()?
Sep
13
awarded  Yearling
Sep
7
awarded  Good Answer
Aug
30
comment How to avoid being an API programmer only?
There's a minor gotcha to 2; many libraries invest considerable amounts of time looking at performance, going far beyond what would be reasonable or sensible for ad-hoc code to look at. I would argue that even "almost always" is misleading. The best that could be argued, either for-or-against, is "sometimes". The trick, as always, is knowing which times.
Aug
13
comment Don't Use “Static” in C#?
@Артём fields are class-level variables; static fields are class-level variables that are per-type rather than per-instance
Aug
13
comment Don't Use “Static” in C#?
static is fine; static fields need to be treated very carefully