I don't think we currently have any design directions or architectural
rules for Geode documented yet other than for GFSH. As we refactor code, we
really should be following some sort of overall design guidelines.
+1 for documenting (on the wiki) and promoting fluent style APIs in our
design guide
For me there is only one real challenge, not an objection as I like builder
and fluent models as well, but there is an added challenge of debugging. it
can effectively combine 5 lines into one, which means it is *slightly* more
annoying to debug, and the fact that return values go away, but for a
b
I really like the Fluent pattern as it is done in C# and Java...
I'm not sure the juice is worth the squeeze in an existing c++ library.
I do agree we should normalize our factory/builder patterns.
On Wed, Sep 6, 2017 at 12:28 PM, Jacob Barrett wrote:
> Mark,
>
> I believe the real issue is th
Mark,
I believe the real issue is that we use multiple patterns and should be
converging on one pattern. We have examples of both Factory and Builder
models and both with and without Fluent pattern.
If the Java API is tending towards Builder model with Fluent pattern then I
am for that as long as
In the geode java apis you would create a CacheFactory (or
ClientCacheFactory), configure it fluently, and then call create at the
end. So even though we call them factories in the geode java apis, they use
the Builder pattern and also support the fluent model in that you could do
this:
ClientCac
Problem:
To fluent and builder model or not to fluent and builder model In the
native client
we use the factory model of generating objects, we are wondering if a move
to the fluent model
and the builder pattern would be better.
Background:
In designing the various types of allocators for