Don't worry... VB.NET will evolve or will die (as Delphi). 2010/2/4 Jason Dentler <jasondent...@gmail.com>
> 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 <srstr...@gmail.com> 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 > > > sboh...@gmail.com <mailto:sboh...@gmail.com> > > >http://blog.unhandled-exceptions.com > > >http://twitter.com/sbohlen > > > > > On Sun, Jan 17, 2010 at 5:40 PM, Fabio Maulo <fabioma...@gmail.com > > > <mailto:fabioma...@gmail.com>> 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 <fabioma...@gmail.com > > > <mailto:fabioma...@gmail.com>> > > > > > 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
