Skip to content
Projects
Groups
Snippets
Help
Loading...
Sign in / Register
Toggle navigation
P
protobuf
Project
Project
Details
Activity
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Board
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Charts
Packages
Packages
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
submodule
protobuf
Commits
007f8596
Commit
007f8596
authored
Aug 14, 2008
by
Jon Skeet
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
First pass of the readme. Lots more to come.
parent
ec8c3955
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
38 additions
and
0 deletions
+38
-0
CSHARP-README.txt
CSHARP-README.txt
+38
-0
No files found.
CSHARP-README.txt
0 → 100644
View file @
007f8596
Readme for the C#/.NET implementation of Protocol Buffers
Copyright 2008 Google Inc.
http://code.google.com/apis/protocolbuffers/
and
http://github.com/jskeet/dotnet-protobufs
(This will eventually be written up into a full tutorial etc.)
Differences with respect to the Java API
----------------------------------------
Many of the changes are obvious "making it more like .NET", but
others are more subtle.
o Properties and indexers are used reasonably extensively.
o newFoo becomes CreateFoo everywhere.
o Classes are broken up much more - for instance, there are
namespaces for descriptors and field accessors, just to make it
easier to see what's going on.
o There's a mixture of generic and non-generic code. This
is interesting (at least if you're a language nerd). Java's generics
are somewhat different to those of .NET, partly due to type erasure
but in other ways too. .NET allows types to be overloaded by the
number of generic parameters, but there's no such thing as the
"raw" type of a generic type. Combining these two facts, I've
ended up with two interfaces for messages, and two for builders -
in each case, a non-generic one and a generic one which derives
from the generic one. Where the members clash (e.g. IBuilder.Build
and IBuilder<TMessage>.Build vary only by return type) the
implementations use explicit interface implementation to provide
the most useful method in most cases. This is very much like
the normal implementation of IEnumerable<T> which extends
IEnumerable. As an aside, this becomes a pain when trying to
create "the read-only version of this list, whose type I don't
know but I know it's a List<something>". Oh for mumble types.
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment