Sorry to derail the conversation. Like I said, I didn't want to bring it up.
On Fri, Feb 5, 2010 at 9:23 AM, Fabio Maulo <[email protected]> wrote: > 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 > >
