This thread is becoming something else than the title... I would like to see some other kind of feedback.
2010/2/5 Diego Mijelshon <[email protected]> > Steve, Jason, > > Just to throw a little more gasoline in the fire... ;-) > Do you know of ANY popular .NET library that's written in VB.NET? > NHibernate... no. Castle... no. Log4net... no. NUnit... no. Automapper... > no. RhinoMocks... no. I could go on. > > The thing is, VB.NET was *NEVER* a first class citizen in the .NET world, > and it will never be. > While supporting it is always good, the biggest effort that's worth is not > using VB reserved words. > > Diego > > > > On Fri, Feb 5, 2010 at 09:44, Stephen Bohlen <[email protected]> wrote: > >> I was under the (general) impression that the next version of VB.NET (to >> ship with the 4.0 framework) is supposed to offer significantly better >> 'semantic parity' with C# (e.g., any construct you can assemble in C# will >> have some correlated statement in VB.NET). >> >> The grand "two primary .NET languages, each with divergent strengths and >> weaknesses" experiment has been acknowledged to be largely a failure for the >> reason you are pointing out and more and so there is an explicit push with >> .NET 4.0 to bring the languages back into semantic near-parity (with the >> probable exception of C# likely *never* getting XML-literals added to >> it...thank god!) >> >> While this won't resolve the issues you're point out for those remaining >> in .NET 3.5, this parity *should* permit those that are willing to go to >> .NET 4.0 to accomplish much of what's shown here (though with an entirely >> different syntax, of course). [note that I haven't verified that statement >> so its entirely possible that you can't construct much of this even in the >> forthcoming VB.NET 10] >> >> After all, if the premise of "right language for the right job" has any >> traction at all in .NET then just as MS wants me to add a VB.NET project >> to my otherwise entirely C# solution in order to manipulate XML literals b/c >> "that language is best for that job", I'm not certain that its all that bad >> to say to a VB.NET developer that they should add a C# project to their >> solution to generate NH mappings because "that's the language that's best >> for that job" :) >> >> I think its pretty clear from watching Microsoft's actions (vs. listening >> to their marketing words) that while both C# and VB.NET are perhaps >> "first-class CLR languages", its also the case that C# is "first among >> equals" within MS and thus I think a C#-leaning API for this is perfectly >> acceptable to pursue even as it might leave VB.NET-only developers with some >> difficulties adopting it until such time as the VB.NET language team >> finds a way to plug the 'gaps' that exist between it and C#. >> >> Just my two cents. >> >> Steve Bohlen >> [email protected] >> >> http://blog.unhandled-exceptions.com >> http://twitter.com/sbohlen >> >> >> On Thu, Feb 4, 2010 at 4:42 PM, Jason Dentler <[email protected]>wrote: >> >>> Hi guys & gals (maybe? probably not) >>> >>> I don't want to mention this for two reasons: >>> #1 - I really like this idea and don't want to be responsible if you >>> decide to kill it. >>> #2 - I am fully aware of the contempt that C# coders have for less >>> developed .NET languages on issues like this. >>> >>> A lot of this syntax simply won't work in the current version of >>> VB.NET. >>> >>> Thanks, >>> Jason >>> >>> On Jan 19, 2:20 am, Steve Strong <[email protected]> wrote: >>> > That's a pretty comprehensive answer! I can't think of anything else >>> to >>> > add over what you've already said - I think an API for creating the >>> > mappings as a core part of NH would be great, and I also agree that >>> > keeping the syntax similar to the current XML eases the learning curve >>> > and also makes porting from XML to code pretty simple. If other want >>> > some different representation (FNH, for example), they now have a >>> > canonical API that they can talk to under the covers, rather than >>> having >>> > to generate xml as they do today. >>> > >>> > I don't have major concerns about the deviation from Hibernate - it's >>> > certainly something that we should bear in mind, but I can't imagine >>> > anything that Hibernate are likely to do wouldn't map to this new API - >>> > anything they add is likely to be configured through XML (I don't see >>> > that going away any time soon), and since the proposed API matches the >>> > XML structure quite closely, I can't see that we'll come across >>> anything >>> > insurmountable. >>> > >>> > Cheers, >>> > >>> > Steve >>> > >>> > On 18/01/2010 16:21, Stephen Bohlen wrote: >>> > >>> > >>> > >>> > > First, some quick impressions: >>> > >>> > > * Its conceptually nice to relegate XML mapping to a less-central >>> > > role within NH (e.g., XML now becomes just ONE of MANY possible >>> > > 'mapping input syntax forms') so I applaud the effort/intent >>> > > * Decoupling mapping + config from XML entirely will definitely >>> > > support many more alternate declarative inputs (custom DSL, >>> > > whatever) in a manner much more flexible than having to depend >>> > > on XML as an 'intermediate translation layer' for NH to consume >>> > > mapping/config info >>> > > * I like that the thrust of the syntax more closely parallels the >>> > > nodes/attributes used in the XML files, making it approachable >>> > > to existing users of XML mapping files (reasonably shallow >>> > > learning curve) even as this leads to a fairly verbose API >>> > > (compared let's say, to something like FNH where 'terse API' >>> was >>> > > --from my reading-- an implicit design goal) >>> > >>> > > Next, some more specific feedback/issues/thoughts/concerns we might >>> > > want to consider (in no particular order): >>> > >>> > > * If this API is to become 'authoritative' for mapping, then by >>> > > extension it clearly needs to completely support all existing >>> > > 'xml constructs' fully >>> > > * Unlike FNH where the authors have taken the entirely valid >>> > > approach of "we're releasing with support for the 80% of NH >>> > > mapping constructs that are most-commonly in use, permitting >>> > > people to weave in xml-based content for the parts we don't yet >>> > > support in code, and over time we will evolve to support the >>> > > remaining 20% edge-cases in the fluent API", IMO for NH this >>> API >>> > > shouldn't be released into the codebase until it has 100% >>> > > functional equivalency with each and every existing XML >>> > > construct and doesn't rely on intermingling xml for any of its >>> > > needs. >>> > > * Obviously as an existing proof-of-concept this isn't yet done >>> > > but it would seem important before making this the >>> authoritative >>> > > API to ensure that adequate spikes are done to be certain that >>> > > for every 'statement' presently possible in XML, there's at >>> > > least an idea about how to express that in this new API (some >>> of >>> > > the edge-cases that come to my mind initially are things like >>> > > the <database-object> elements, stored procedures, filter >>> > > statements, where statements, etc. that aren't immediately >>> > > obvious from the sample code in the blog post re: how they >>> would >>> > > be addressed -- basically the entire category of things >>> > > presently definable in XML that aren't necessarily *directly* >>> > > about mapping entities per-se but that are about caching >>> > > directives, other DB elements, etc.) >>> > > * We need to ensure that adequate consideration is given to how >>> > > this API would express things that aren't immediately possible >>> > > to state as lambda's without some 'tricks' via reflection, etc. >>> > > For example, this kind of statement from the sample code... >>> > >>> > > map.Class<Animal,long>(animal => animal.Id, id => id.Generator >>> =Generators.Native, rc => >>> > > ...won't work where the POID is actually not a public property of the >>> > > Animal class but is instead a private field and of course the >>> > > statement (animal => animal._persistentId, ... won't compile b/c the >>> > > private field _persistentId is not visible to intellisense (or more >>> > > importantly, the compiler!). To be sure, there are 'tricks' to get >>> > > around this lambda limitation, but I recommend that we should >>> consider >>> > > carefully what this will look like when invoked via this API to be >>> > > sure its as clear as the public-property-based mappings shown in the >>> > > sample code. >>> > >>> > > * How does moving this fluent-API into the role of 'primary' >>> > > mapping API affect NH's 'parity' with Hibernate? Is it >>> possible >>> > > that Hibernate might get a future feature that would want to be >>> > > ported to NH but we would find that this (hypothetical) new >>> > > feature isn't expressible in the new fluent API? Obviously >>> > > nobody can predict the future, but the move to this API as >>> > > 'primary' mapping API would seem to represent a digression from >>> > > NH's close parity with H which may impact the ease with which >>> > > future features can be ported from H to NH. This new fluent >>> API >>> > > might very well be a useful/valuable digression (and obviously >>> > > there are already OTHER features that have been added to NH >>> that >>> > > take advantage of the .NET platform and don't have an allegory >>> > > in Hibernate so diverting from exact parity with H isn't >>> without >>> > > precedent), but IMO we should carefully consider its potential >>> > > future impact on porting H features to NH before we decide to >>> > > 'deprecate' XML as the primary/core mapping API. >>> > >>> > > In short: I like the approach, think it will be quite valuable and >>> > > helpful to anyone trying to write inputs to the NH mapping/config API >>> > > in the future, but recommend that we consider the above >>> > > issues/thoughts before introducing this API as a 'replacement' for >>> the >>> > > primacy of the xml API in the project. >>> > >>> > > HTH, >>> > >>> > > Steve Bohlen >>> > > [email protected] <mailto:[email protected]> >>> > >http://blog.unhandled-exceptions.com >>> > >http://twitter.com/sbohlen >>> > >>> > > On Sun, Jan 17, 2010 at 5:40 PM, Fabio Maulo <[email protected] >>> > > <mailto:[email protected]>> wrote: >>> > >>> > > Please, I'm needing feed-back coming from code-review. >>> > >>> > > Try to think at it as a possible mapping-by-code solution for >>> NH3.0. >>> > > I'm seriously thinking to add it in NH directly. >>> > >>> > > 2010/1/13 Fabio Maulo <[email protected] >>> > > <mailto:[email protected]>> >>> > >>> > > Hi team. >>> > >>> > > I would like to have a code re-view of my last post and >>> > > a constructive feedback >>> > > >>> http://fabiomaulo.blogspot.com/2010/01/map-nhibernate-using-your-api.... >>> > >>> > > The post, and overall the code, is basically an example about >>> > > how implement a custom API to create mappings by code. >>> > > That is an invitation to everybody want create his own API >>> and >>> > > even an invitation for FNH team to use the Hbm* classes >>> > > instead generate XML. >>> > >>> > > That said, seeing how things are going in each framework, NH >>> > > needs its own mapping-by-code. >>> > > Two matters here: >>> > > 1) API definition >>> > > 2) usage of Hbm* or directly create metadata (classes of >>> > > namespace NHibernate.Mapping) >>> > >>> > > What is clear is that our implementation will supports >>> > > anything supported by XML and, probably, we will improve some >>> > > of actual "conventions-interceptors" (as, for instance, >>> > > INamingStrategy & Co. ). >>> > >>> > > -- >>> > > Fabio Maulo >>> > >>> > > -- >>> > > Fabio Maulo >>> >> >> > -- Fabio Maulo
