Current idea is to:
- deprecate current "ALL_KEYS" and List passing behavior in
registerInterest()
- add registerInterestAllKeys();
- add registerInterest(T... keys) and registerInterest(Iterable<T>keys) and
not have one specifically for List or specific collections.
The Iterable version would handle any collection type by having the user
pass in the iterator for the collection.
On Fri, Nov 17, 2017 at 11:32 AM Jacob Barrett <jbarr...@pivotal.io> wrote:
> I am failing to see where registerInterest(List<T> keys) is an issue for
> the key type in the region. If our region is Region<String> then I would
> expect registerInterest(List<String>). If the keys are unknown or a mix
> then you should have Region<Object> and thus registerInterest(List<Object).
>
> I echo John's statements on VarArgs and type erasure as well as his
> argument for Iterable<T>.
>
> Also, List<T> does not restrict you from List indexes. The region would be
> Region<List<String>> with registerInterest<List<List<String>>().
>
> -Jake
>
>
> On Fri, Nov 17, 2017 at 10:04 AM John Blum <jb...@pivotal.io> wrote:
>
> > Personally, I prefer the var args method (registerInterest(T... keys))
> > myself. It is way more convenient if I only have a few keys when calling
> > this method then to have to add the keys to a List, especially for
> testing
> > purposes.
> >
> > But, I typically like to pair that with a registerInterest(Iterable<T>
> > keys) method
> > as well. By having a overloaded Iterable variant, then I can pass in any
> > Collection type I want (which shouldn't be restricted to just List). It
> > also is a simple matter to convert any *Collection* (i.e. *List*, *Set*,
> > etc) to an array, which can be passed to the var args method. By using
> > List,
> > you are implying that "order matters" since a List is a order collection
> of
> > elements.
> >
> > This ("*It might even cause problems of pushing in **multiple different
> > types.*"), regarding var args, does not even make sense. Technically,
> > List<T> is no different. Java's type erasure essentially equates var
> args
> > too "Object..." (or Object[]) and the List<T> to List (or a List of
> > Objects,
> > essentially like if you just did this... List<Object>) So, while the
> > compiler ensures compile-time type-safety of generics, there is no
> generics
> > type-safety guarantees at runtime.
> >
> >
> >
> > On Fri, Nov 17, 2017 at 9:22 AM, Jason Huynh <jhu...@pivotal.io> wrote:
> >
> > > Hi Mike,
> > >
> > > The current support for List leads to compilation issues if the region
> is
> > > type constrained. However I think you are suggesting instead of a var
> > args
> > > method, instead provide a registerInterest(List keys) method?
> > >
> > > So far what I am hearing requested is:
> > > deprecate current "ALL_KEYS" and List passing behavior
> > > registerInterestAllKeys();
> > > registerInterest(List<T> keys) instead of a registerInterest(T... keys)
> > >
> > > Will anyone ever actually have a List as the key itself? The current
> and
> > > suggested changes would not allow it registering for a specific List
> > > object.
> > >
> > >
> > >
> > > On Thu, Nov 16, 2017 at 6:50 PM Jacob Barrett <jbarr...@pivotal.io>
> > wrote:
> > >
> > > > Geode Native C++ and .NET have:
> > > >
> > > > virtual void registerKeys(const
> > > > std::vector<std::shared_ptr<CacheableKey>> & keys,
> > > > bool isDurable = false,
> > > > bool getInitialValues = false,
> > > > bool receiveValues = true) = 0;
> > > >
> > > > virtual void unregisterKeys(const
> > > > std::vector<std::shared_ptr<CacheableKey>> & keys) = 0;
> > > >
> > > > virtual void *registerAllKeys*(bool isDurable = false,
> > > > bool getInitialValues = false,
> > > > bool receiveValues = true) = 0;
> > > >
> > > > virtual void unregisterAllKeys() = 0;
> > > >
> > > > virtual void registerRegex(const std::string& regex,
> > > > bool isDurable = false,
> > > > bool getInitialValues = false,
> > > > bool receiveValues = true) = 0;
> > > >
> > > > virtual void unregisterRegex(const char* regex) = 0;
> > > >
> > > > I dislike special values like this so yes please make it go away!
> > > >
> > > > -Jake
> > > >
> > > >
> > > > On Thu, Nov 16, 2017 at 5:20 PM Dan Smith <dsm...@pivotal.io> wrote:
> > > >
> > > > > I don't really like the regex option - it implies that your keys
> are
> > > all
> > > > > strings. Will any other regular expressions work on non string
> > objects?
> > > > > registerInterestAllKeys() seems like a better option.
> > > > >
> > > > > -Dan
> > > > >
> > > > > On Thu, Nov 16, 2017 at 4:34 PM, Michael Stolz <mst...@pivotal.io>
> > > > wrote:
> > > > >
> > > > > > I don't like the vararg option.
> > > > > > If i'm maintaining a list of keys i'm interested in, I want to be
> > > able
> > > > to
> > > > > > pass that List in.
> > > > > > Varargs is a poor substitute. It might even cause problems of
> > pushing
> > > > in
> > > > > > multiple different types. Keys must all be of one type for a
> given
> > > > > Region.
> > > > > >
> > > > > >
> > > > > > I'm very much in favor of deprecating the ALL_KEYS string in
> favor
> > of
> > > > > > something that is typed specially if you refer to ALL_KEYS.
> > > > > >
> > > > > >
> > > > > > If that works, then we don't necessarily need the additional API
> > > > > > registerInterestAllKeys(). But if ALL_KEYS can't be a special
> type
> > to
> > > > get
> > > > > > over the compilation issues then we should go with the new API.
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Mike Stolz
> > > > > > Principal Engineer, GemFire Product Lead
> > > > > > Mobile: +1-631-835-4771 <(631)%20835-4771> <(631)%20835-4771>
> <(631)%20835-4771>
> > <(631)%20835-4771>
> > > > > >
> > > > > > On Thu, Nov 16, 2017 at 7:02 PM, Anilkumar Gingade <
> > > > aging...@pivotal.io>
> > > > > > wrote:
> > > > > >
> > > > > > > +1 Deprecating ALL_KEYS option; I believe this is added before
> we
> > > > > > supported
> > > > > > > regex support.
> > > > > > >
> > > > > > > Doesn't seems like a new API is needed. The regex java doc
> > clearly
> > > > > > > specifies the effect of ".*".
> > > > > > >
> > > > > > > +1 for deprecating list argument; and replacing with new API.
> > > > > > >
> > > > > > > -Anil.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Thu, Nov 16, 2017 at 3:36 PM, Jason Huynh <
> jhu...@pivotal.io>
> > > > > wrote:
> > > > > > >
> > > > > > > > For GEODE-3813 <
> > https://issues.apache.org/jira/browse/GEODE-3813
> > > >:
> > > > > > > Region
> > > > > > > > registerInterest API usage of type parameters is broken
> > > > > > > > <https://issues.apache.org/jira/browse/GEODE-3813>
> > > > > > > >
> > > > > > > >
> > > > > > > > The current API to registerInterest allows a special string
> > token
> > > > > > > > “ALL_KEYS” to be passed in as the parameter to
> > registerInterest(T
> > > > > key).
> > > > > > > > This special token causes the registerInterest to behave
> > similar
> > > to
> > > > > > > > registerInterestRegex(“.*”). As the ticket states, if the
> > region
> > > > has
> > > > > > > been
> > > > > > > > typed to anything other than Object or String, the usage of
> > > > > “ALL_KEYS”
> > > > > > > as a
> > > > > > > > parameter results in a compilation error.
> > > > > > > >
> > > > > > > >
> > > > > > > > Proposals:
> > > > > > > >
> > > > > > > > I would like to deprecate the special string “ALL_KEYS” and
> > > > document
> > > > > a
> > > > > > > > workaround of using registerInterestRegex(“.*”) or we can
> add a
> > > new
> > > > > API
> > > > > > > > called registerInterestAllKeys()
> > > > > > > >
> > > > > > > >
> > > > > > > > I think we should also deprecate passing a List Object of
> keys
> > > into
> > > > > > > > registerInterest. It has the same compilation restrictions
> as
> > > > > > “ALL_KEYS”
> > > > > > > > when the region is key constrained/typed. The reason why
> List
> > > > would
> > > > > be
> > > > > > > > used is to allow registering multiple keys at once. Instead,
> > we
> > > > can
> > > > > > add
> > > > > > > a
> > > > > > > > new var arg API like registerInterest(T… keys). This problem
> > and
> > > > > > > solution
> > > > > > > > was also documented in the ticket by the ticket creator (Kirk
> > > Lund)
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > >
> > > > > > > > -Jason
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > -John
> > john.blum10101 (skype)
> >
>
