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 >
