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 >> > >
