All this would be much more elegant if we'd used Ruby... (I kid! I kid!)
On 7/18/06, Hugh Perkins <[EMAIL PROTECTED]> wrote:
On 7/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Would these classes be generated once-per-class-per-runtime or regenerated for every class instance created? Once per class per runtime. Once they're generated they're essentially like any other class in your program. There are actually two stages in the lifetime of an Emitted class, note these names are not official names: - Creation phase. You can define methods, properties etc, generally mess around with the class. No actual class exists yet, you cant use the class yet. - Usage phase. The class is created and becomes just like any other class in your program, for most intents and purposes. You can no longer modify the properties or methods of the class. You initiate the Creation phase by calling DefineType on a modulebuilder object, passing in the name of the new class. This gives you a typebuilder object. You initiate the Usage phase by calling CreateType on this typebuilder object. Once the type has been created it remains in your program for the remainder of its execution time. On 7/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > > Would these classes be generated once-per-class-per-runtime or regenerated for every class instance created? > > > > ________________________________ > > From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf Of Tom Wilson > Sent: Monday, July 17, 2006 11:51 AM > > To: Development list for libsecondlife > > Subject: Re: [libsecondlife-dev] Industrialized Rpc Outbound? > > > > > > > > I like Reflection. I frequently use it to populate list boxes with enums, for example. > > Personally, I like the idea of generating the code automatically, but not at run-time. If it's possible to auto-generate new C# modules for each packet type, it shouldn't be too much work to re-compile the library with those new classes. It also gives us a place to go to look for bugs, errors, or just plain misunderstandings about the protocol (such as the IM bug that I found). > > Generating the classes on the fly sounds interesting, but for a program that will run 24/7, such as a messaging gateway or a vendor, I can see some potential issues. The biggest one is probably the fact that .Net is a memory and CPU hog. I think it's our responsiblity to make our programs as lightweight as possible, considering the fact that PC's already have so many daemons running these days. Considering all the background processes on my computer, it seems like my 2.8GHz Pentium is actually slower some days than my old 286 AT that I had when I installed my first copy of Windows. :-) > > > On 7/16/06, John Hurliman < [EMAIL PROTECTED]> wrote: > > Just remember that using reflection won't automatically make all of the > manual packet handling go away. Two example are ParcelOverlay, which > comes in four separate packets and has to be reassembled in to a single > byte array, and almost anything with a Data field that is the LL way of > doing polymorphic fields. MultipleObjectUpdate is a good example of this. > > It will (if I understand correctly) remove all the repetitive work of > disassembling incoming packets though. We already have a system in place > where each packet has a name and full structure and type information; > leveraging C# abilities with this information is the next logical step. > I'm still wondering if anonymous types could be used for the dynamic > class generation though, or are they not suited for the task? > > John > > _______________________________________________ > libsecondlife-dev mailing list > libsecondlife-dev@gna.org > https://mail.gna.org/listinfo/libsecondlife-dev > > > > > -- > Tom Wilson > [EMAIL PROTECTED] > KI6ABZ > > _______________________________________________ > libsecondlife-dev mailing list > libsecondlife-dev@gna.org > https://mail.gna.org/listinfo/libsecondlife-dev > > > _______________________________________________ libsecondlife-dev mailing list libsecondlife-dev@gna.org https://mail.gna.org/listinfo/libsecondlife-dev
-- --Jesse _______________________________________________ libsecondlife-dev mailing list libsecondlife-dev@gna.org https://mail.gna.org/listinfo/libsecondlife-dev
