I can see one problem here -- nothing prevents you from specifying more than one @DefaultValue and you may get a conflict too late, as far as I see you can't control this. Have you thought about it?
On Tue, May 28, 2013 at 12:23 AM, Eli Doran <e...@elidoran.com> wrote: > I've used @Symbols a lot. I appreciate its flexibility and coercion > ability. > > I started programming around it though and instead accessing SymbolSource > and TypeCoercer directly because it is missing the ability to specify a > default value, and the ability to ignore when a value can't be found. > > I made another service which uses SymbolSource and TypeCoercer to accept a > default value and avoid throwing an exception when a value isn't found. > > The more I use this the more I miss simply using @Symbol on a parameter. I > have to inject this new service and make the method call (I know, little > work really). > > I keep thinking adding an optional default parameter to @Symbol, or another > annotation like @DefaultValue would enhance the current functionality > without affecting how everyone is currently using it and how it behaves. > > Is this something the flexibility of Tap IoC would allow me to override > some processors or decorate current services to alter in my own > applications? > > Is this something anyone else is interested in having in Tapestry IoC? > > > A part of my motivation for this is it seems a nuisance being required to > put a default symbol value in the FactoryDefaults/ApplicationDefaults for > every use of @Symbol. I want to retain the distributed configuration so it > can be overridden but often I'd rather specify the default value in the > class using the Symbol. It keeps things together. > > Thank you > -- Dmitry Gusev AnjLab Team http://anjlab.com
