A dotnet moniker could be a lot more interesting, if there were a standard way to represent simple properties as strings and some library to find the best match.
For example, foo![name="Doug"][age=33] the underlying dotnet moniker runtime could find properties in the object that match in type to the values supplied and make the assignments. > -----Original Message----- > From: Doug Ransom > Sent: Thursday, June 26, 2003 3:07 PM > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] Constructing Objects From Strings in > dotnet > > > I think the Moniker interfaces were a little hard to use, and > not well explained on MSDN. I think Monikers would have > caught on if there were a lot of concrete examples on MSDN > and Microsoft had pushed them a little bit. Some recommended > syntax and available parsing routines would have helped. > Once I learned how to write monikers, it became quite easy. > > Who can we lobby to ask for a moniker system for dotnet? > > Doug > > > -----Original Message----- > > From: Kjell Arild Tangen [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, June 24, 2003 11:39 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [ADVANCED-DOTNET] Constructing Objects From Strings in > > dotnet > > > > > > I agree that COM makes monikers hard to use. It is a pity, > > because I see it as a very valuable pattern to use in > > instances when a generic service needs to mediate objects of > > virtually any kind. I would love to see a .NET moniker > > implementation that is simple to use and just as elegant and > > extensible as its COM predecessor. > > > > The moniker pattern is about separating object binding from > > object use. This way object binding (activation) can be > > delegated to generic services not knowing anything about the > > object they activate, while consumers of these services may > > use these objects without having to know how to activate > > them. In the COM world, this was the basis for OLE, and OLE > > containers were just an example of a generic service that > > knows about object binding, not about the object itself. > > > > The usefulness of the moniker pattern comes from having a > > unified and extensible way of encoding complex object binding > > semantics into a symbolic object reference (the moniker). > > This way all complexity and mechanics of binding to a > > particular instance can be separated from actual use of the > > object, and the object reference (moniker) can be passed > > around to anyone that need to use that particular object. The > > object consumer would only have to know how to use the target > > object, not how to bind to it. > > > > Regards, > > Kjell > > > > > > > > But they [Monikers] didn't catch on properly because they > > > were so incredibly complicated! Programmers often asked > > > themselves: why not just directly use a file path or a URL - > > > or a table? Why do I have to perform 27 steps just to locate > > > an object? > > > > > > Truth be known, I've just implemented a set of polymorphic > > > Moniker objects in a current distributed project of mine and > > > I'm beginning to realise that it actually hasn't simplified > > > my design pattern much at all.. (Quite the opposite, in > > > fact.) But despite this, I think Monikers (implemented in a > > > programmer-accessible fashion) are a natural part of any > > > system where things need to be elegantly located and accessed > > > - such as .NET remoting. > > > > > >
