Hi guys, Thanks John for starting this thread.
IMO we need to weight pragmatism, low friction for real life usage and good layering very carefully here. I agree with John that Core should not be a dumping ground for all the small projects we have.
As of now (v2.5.1) there are following things living in Castle.Core.dll (harvested with NDepend and Excel)
namespaces # IL instructions Full NameCastle.Components.DictionaryAdapter 10 304 Castle.Components.DictionaryAdapter
Castle.DynamicProxy.Generators 5 759 Castle.DynamicProxy.Generators Castle.DynamicProxy.Contributors 4 368 Castle.DynamicProxy.Contributors Castle.DynamicProxy 3 658 Castle.DynamicProxyCastle.DynamicProxy.Generators.Emitters 2 890 Castle.DynamicProxy.Generators.Emitters
Castle.Core.Logging 1 515 Castle.Core.LoggingCastle.DynamicProxy.Generators.Emitters.SimpleAST 1 503 Castle.DynamicProxy.Generators.Emitters.SimpleAST
Castle.Core.Resource 1 221 Castle.Core.Resource
Castle.DynamicProxy.Tokens 509 Castle.DynamicProxy.Tokens
Castle.Core 474 Castle.Core
Castle.DynamicProxy.Serialization 401
Castle.DynamicProxy.Serialization
Castle.Core.Internal 330 Castle.Core.Internal
Castle.Core.Smtp 284 Castle.Core.Smtp
261
Castle.Core.Configuration 142 Castle.Core.Configuration
Castle.DynamicProxy.Generators.Emitters.CodeBuilders 132
Castle.DynamicProxy.Generators.Emitters.CodeBuilders
Castle.Core.Configuration.Xml 112 Castle.Core.Configuration.Xml So to recap we have (and my thoughts)- DynamicProxy which is literally used by every project which is using Core anyway (and not just inside of Castle - DP is probably one of the most widely used OSS libraries throughout .NET) - Dictionary Adapter, which kind of complements DP in many of ways and for vNext I'd like to extract commonalities between DP and DA to common classes as well so that they don't duplicate each other. I still think that having DA in Core is from pragmatic perspective a good choice, and having it here will allow me to take advantage of its capabilities in Windsor vNext - logging adapters which kind of make sense and are widely used so I guess they should stay as they are, although I'm noticing push towards using built in .NET logging capabilities recently. - resources abstractions - in Windsor used solely by XmlInterpreter. Probably Monorail or AR depend on it in a greater degree (?) - root namespace which contains few random types. I didn't investigate who is using them to what degree. One thing I think worth doing is getting rid of Pair<,> in favor of Tuple<,> in .NET 4 - internal - contains abstractions used internally to abstract differences between .NET and Silverlight - Smtp - contains EmailSender component (this is one class and one interface)
- empty - contains types autogenerated by the compiler- Configuration - abstractions over configuration. Used extensively in Windsor
In other words - I think two biggest chunks of Core we have right now, DP and DA well mandate their existence there and most of the other stuff can't really be moved either so I think Core should stay the way it is now. I'm strongly agains adding any more stuff to Core. I agree with Ayende on this one: http://ayende.com/Blog/archive/2009/04/29/let-us-burn-all-those-pesky-util-amp-common-libraries.aspx
We have to also remember that we ship a Silverlight version of it, which is quite popular (to my surprise) and size is a big factor in Silverlight so this also needs to be factored in.
cheers, Krzysztof On 23/09/2010 8:01 AM, John Simons wrote:
There has been a bit of debate about Castle.Core, what to have in it and what shouldn't be in it. The point of this thread is to try to come to some consensus/decision on this matter.So I start, I see Castle.Core having the bare minimum, example, helper classes, extension methods, no dependencies on external assemblies, no features (see below), no volatile stuff.I do consider DP + DA features and quite volatile!Do we need Castle.Core and Castle.Core.Features ? or Castle.Common, Castle.Base, ......What's your thoughts? Cheers John --You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
-- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
<<inline: moz-screenshot.png>>
