Re: [Springframework-developer] Sad but true, was Another BeanFactory feature

[Colin S. <col...@ex...>]

To reverse the old adage, 'one man's poison is another man's meat'. I 
honestly don't think that what you're describing is possible, since 
different things are of different value to different people. On top of 
that, Spring is made up of various components, so it's hard to do 
something such as cut out a swath of functionality across the whole thing.

At the end of the day, I think as the project (any project really) 
devleops, you have to constantly look at the value of the new features 
you are adding (and there is more than one way to define value), decide 
whether they are worth having at all, and try to come up with some 
sensible defaults and usage and configuration mechanisms that achieve 
the right balance in all these aspects such as ease of use, power, 
reliability, marketing, etc. I know this is vague, but I really think it 
has to be done on a case by case basis, and handled in that fashion it 
is manageable and possible.

Regards,
Colin


Rob Butler wrote:

>Sad but true (Metallica)
>
>It's pretty sad when an open source, well architected project has to add
>features that are of little use or ones that they "don't really recommend"
>for "marketing" value.  I know it's true that open source projects need to
>be concerned as much with marketing these days as commercial software.  It's
>just sad to have it be so true, since many open source projects are attempts
>to get away from the marketing and hype and deliver a quality (free)
>technically superior piece software.
>
>Back to the matter at hand, I can see the value in having the "automagical"
>wiring, and I can also see the value in not having the automagical stuff.
>How about adding a feature to the framework that ALL the automagical stuff
>can be declaritively turned on/off(disabled) with just one setting, by
>default it is off(disabled).  In that way, any attempt to use the
>automagical features in the config files throws an error on startup.  Also
>"autowiring", etc would be disabled.  This (I think) would make both crowds
>happy because those who want automagical stuff can use it, they would just
>specifically have to turn it ON for the framework before using the
>automagical features in code / config files.  Those who don't can leave it
>turned off.
>
>Later
>Rob
>
>
>+1
>
>I agree it's not really to recommend. But marketing has to be taken in
>account.
>
>Jean-Pierre
>
>-----Message d'origine-----
>De : spr...@li...
>[mailto:spr...@li...] De la
>part de Rod Johnson
>Envoyé : jeudi 4 septembre 2003 23:42
>À : Ivan Ristic
>Cc : spr...@li...
>Objet : Re: [Springframework-developer] Another BeanFactory feature
>
>  
>
>>   In a way, wiring the beans manually is a form of documentation
>>   how system works. So, if it were up to me I would cancel all
>>   automagical processes. Besides, we will probably soon have GUI
>>   tools to configure our beans with and that will be more fun
>>   anyway.
>>    
>>
>
>I'm inclined to agree. But I think the marketing advantage is real, as
>the
>"objects cannot be in an inconsistent state" argument is the only thing
>PicoContainer can really claim as an advantage over Spring. Even if we
>don't
>use it, and don't really recommend it, this neutralizes that claim.
>
>  
>