PicoContainer
  1. PicoContainer
  2. PICO-206

Constraint-based collection dependency instantiation

          Details

          • Type: Improvement Improvement
          • Status: Closed Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: None
          • Fix Version/s: 1.1
          • Component/s: None
          • Labels:
            None
          • Number of attachments :
            1

            Description

            I've been struggling with collection/array/composite-style dependencies (see PICO-202) and wrote these implementations of the Parameter interface as a more flexible way of configuring dependencies on collections and arrays.

            Advantages over existing GenericCollectionComponentAdapter:

            • Implementation feels cleaner than the way that GCCA is currently integrated into ComponentParameter – paves the way for some refactoring cleanup of ComponentParameter
            • Supports dependencies on pre-JDK1.5 Collections.
            • Default behavior is to fill a collection with every other component in the container, but included Constraint classes allow filtering/narrowing of the instances to include.
            • Constraints can be applied to array dependencies as well (for wide-open Object[] dependencies)
            • Automatically filters out the target adapter to avoid a cyclic dependency (this seems to be broken in the current code, see the ConstraintIntegrationTestCase.FAILtestUnambiguousTouchableDependency test)

            So, just thought I'd submit the code and see if there is any interest in using this approach going forward.

            Looking forward to see what you all think!

            /Nick

              Issue Links

              is related to

              Improvement - An improvement or enhancement to an existing feature or task. PICO-181 refactor creation of default parameters

              • Minor - Minor loss of function, or other problem where easy workaround is present.
              • Open - The issue is open and ready for the assignee to start work on it.
              is superceded by

              Improvement - An improvement or enhancement to an existing feature or task. PICO-236 Invent picocontainer-gems

              • Major - Major loss of function.
              • Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.

                Activity

                Nick Sieger made changes -
                Field Original Value New Value
                Attachment parameter-constraints.tar.gz [ 12870 ]
                Hide
                Permalink
                Nick Sieger added a comment -

                Two more potential improvements:

                • CollectionConstraint could be used in InstantiatingComponentAdapter.createDefaultParameters when a Collection or array type is detected
                • Could envision a NanoGroovyBuilder constraint syntax using and(), or(), not(), key(), type(), etc.
                Show
                Nick Sieger added a comment - Two more potential improvements: CollectionConstraint could be used in InstantiatingComponentAdapter.createDefaultParameters when a Collection or array type is detected Could envision a NanoGroovyBuilder constraint syntax using and(), or(), not(), key(), type(), etc.
                Hide
                Permalink
                Aslak Hellesøy added a comment -

                It's nice that you are contributing this.

                Before we apply this contribution I need to know:

                1) Is this a workaround for a use case that cannot be achieved with the current support for arrays?

                2) If this attempts to solve something that cannot be solved with arrays, what is your case?

                3) Would you accept an implementation that leverages generics (and jdk 1.5?)

                Show
                Aslak Hellesøy added a comment - It's nice that you are contributing this. Before we apply this contribution I need to know: 1) Is this a workaround for a use case that cannot be achieved with the current support for arrays? 2) If this attempts to solve something that cannot be solved with arrays, what is your case? 3) Would you accept an implementation that leverages generics (and jdk 1.5?)
                Hide
                Permalink
                Nick Sieger added a comment -

                1. It started as a workaround, but grew a little further out of that. I've since written a testcase and patch which obviates the need for the workaround (see PICO-207), which makes this code more of an add-on feature.

                2. I can't think of anything at the moment that this would solve that couldn't be done with arrays, other than further specification/narrowing of what you want in your collection/array in a container that might have many components of the same type and you wish to configure a component that doesn't receive all of them. No concrete example right now.

                3. A generics implementation will be nice but doesn't add much on top of what's achievable with arrays today. I also probably won't see JDK1.5 for a while in my work-related projects anyway due to appserver vendors typically taking awhile to formally support it (my IT dept. won't move to a new JDK until it's supported by the appserver vendor).

                Show
                Nick Sieger added a comment - 1. It started as a workaround, but grew a little further out of that. I've since written a testcase and patch which obviates the need for the workaround (see PICO-207 ), which makes this code more of an add-on feature. 2. I can't think of anything at the moment that this would solve that couldn't be done with arrays, other than further specification/narrowing of what you want in your collection/array in a container that might have many components of the same type and you wish to configure a component that doesn't receive all of them. No concrete example right now. 3. A generics implementation will be nice but doesn't add much on top of what's achievable with arrays today. I also probably won't see JDK1.5 for a while in my work-related projects anyway due to appserver vendors typically taking awhile to formally support it (my IT dept. won't move to a new JDK until it's supported by the appserver vendor).
                Jörg Schaible made changes -
                Link This issue is superseded by NANO-99 [ NANO-99 ]
                Jörg Schaible made changes -
                Link This issue is superseded by NANO-99 [ NANO-99 ]
                Jörg Schaible made changes -
                Link This issue is superseded by NANO-99 [ NANO-99 ]
                Jörg Schaible made changes -
                Link This issue is related to PICO-181 [ PICO-181 ]
                Hide
                Permalink
                Jörg Schaible added a comment -

                Refactored to use new CollectionComponentAdapter.
                Thanks to Nick Sieger for original idea and code contribution.

                Show
                Jörg Schaible added a comment - Refactored to use new CollectionComponentAdapter. Thanks to Nick Sieger for original idea and code contribution.
                Jörg Schaible made changes -
                Fix Version/s 1.1 [ 10307 ]
                Resolution Fixed [ 1 ]
                Status Open [ 1 ] Closed [ 6 ]

                  People

                  • Assignee:
                    Unassigned
                    Reporter:
                    Nick Sieger
                  • Votes:
                    0 Vote for this issue
                    Watchers:
                    0 Start watching this issue

                    Dates

                    • Created:
                      Updated:
                      Resolved: