Decoupled ParseObject subclassing #61
Conversation
Parse/Parse.csproj
Outdated
There was a problem hiding this comment.
More line-ending BS. I'll try and fixup this part of the commit.
There was a problem hiding this comment.
Does it make sense to do this during initialization and drop the mutex? Or, to put it more succinctly, is there ever a time when you would register a subclass but never need to look up the property mappings?
There was a problem hiding this comment.
That makes sense. Let's put this inside initialization and drop the mutex. Every call to [], Set, Remove, or even a simple ObjectId will call this props. So optimistically creating this this for every subclass will always be useful.
richardjrossiii
force-pushed
the
richardross.subclassing.decouple
branch
from
c45e7d9 to
e7caf82
Compare
There was a problem hiding this comment.
curious, any reason we're using ReaderWriterLockSlim here instead of using usual lock(mutex) other than the performance boost it gives?
There was a problem hiding this comment.
@hallucinogen that's really the only reason. I figure this will be a high-throughput critical section, and for most accesses there's no need to be exclusive.
|
The build is failing. And the cause seems valid |
richardjrossiii
force-pushed
the
richardross.subclassing.decouple
branch
2 times, most recently
from
aff163d to
435559a
Compare
Similar to the subclassing architecture used on iOS, this abstracts and cleans up all of the code relating to subclassing that currently resides inside of ParseObject.
richardjrossiii
force-pushed
the
richardross.subclassing.decouple
branch
from
435559a to
95cfdb4
Compare
There was a problem hiding this comment.
ah. I see it. This is good.
|
Well done! |
…ouple Decoupled ParseObject subclassing
Similar to the subclassing architecture used on iOS, this abstracts and cleans up all of the code relating to subclassing that currently resides inside of ParseObject.
Tests coming soon™.