More collection-like naming of space methods, more consistency.
---------------------------------------------------------------

                 Key: RIVER-380
                 URL: https://issues.apache.org/jira/browse/RIVER-380
             Project: River
          Issue Type: Wish
          Components: com_sun_jini_outrigger, net_jini_space
            Reporter: James Grahn
            Priority: Minor


The following methods on JavaSpace05 have names that fall outside of the 
natural naming established in the original JavaSpace interface "contents", 
"take (with a collection)", and "write (with a list)".

I suggest the following renamings:
contents -> readAllExisting
take (with collection) -> takeAny
write (with list) -> writeAll

This would eliminate the awkward overloading of "take" and "write" while 
bringing "contents" into a consistent naming plan.

The goal is a naming scheme which clearly communicates functionality:
"exists/existing" suffix = nonblocking call (waits within timeout if no 
template match found)
"any" suffix = one or more templates will be satisfied, multi-return
"all" suffix = all templates will be satisfied, multi-return
If unmodified, standard blocking call.

The clearer naming also points to new functionality we could choose to support, 
namely:
readAll - blocking call with all templates
readAny - blocking call on any template
takeAllExisting - nonblocking call with multiple templates.
takeAll - blocking call with all templates


Addendums:
1) I'll admit that "any" is the weakest part of the syntax, as it fails to 
connote the multi-return.   I was stretching to cover the current "take (with 
collection)" semantics, which blocks until at least one template match is 
available.   Open to better suggestions.

2) Though generally I dislike overloading methods, there is one case I'm 
sympathetic to: overloading "all" and "allExisting" methods to take in a 
single template or multiple templates.   This would save some calls to 
Collections.singleton() for our users while maintaining a consistent return 
type for the method.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to