Yeah, that's exactly the difference. Derek
-----Original Message----- From: Nicholas Muguira [mailto:[EMAIL PROTECTED] Sent: Thursday, November 17, 2005 11:01 AM To: [EMAIL PROTECTED] Cc: WiX-devs Subject: Re: [WiX-devs] rfc: re-architect wix extensions Derek: sorry for the multiple mails, I keep forgetting that just clicking on the space to reply isn't reply to all in gmail =/. OK, I don't really use .net at all, so I'm not familiar with how it handles inheritance. I presume from your statement above that the interfaces are purely virtual (specify the form that the class should take but provide no functionality). If so, then you are probably right if you want to break it up it would have to be aggregated. Really the only difference I see between the two is that one returns a member variable and the other one returns itself cast as something different. On 11/17/05, Derek Cicerone <[EMAIL PROTECTED]> wrote: > Adding back wix-devs. > > Sorry, I'm afraid I don't follow. In .net 1.1, a class cannot span multiple > sources files and cannot implement multiple base classes (only multiple base > interfaces). So method 1 would force all the necessary concrete extension > methods for the various tools to appear in a single extension class, right? > Only the second method allows us to partition the different extensions into > their own classes and thus source files. > > Derek > > -----Original Message----- > From: Nicholas Muguira [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 17, 2005 10:32 AM > To: [EMAIL PROTECTED] > Subject: Re: [WiX-devs] rfc: re-architect wix extensions > > Oh, to continue, there is no reason to not keep the seperate pieces in > seperate source files, b/c method one will just use Multiple > Inheritence like many COM objects do. Now, if MI needs to be avoided, > it probably is best to go the second route. > > On 11/17/05, Nicholas Muguira <[EMAIL PROTECTED]> wrote: > > OK, my take on all this. > > > > This is all starting to look and sound very COMish, and the two things > > are really the same as regular COM objects and aggregate objects. For > > example > > > > Method #1 > > > > public class INicksWixExtension : > > public IWixExtensionBase, > > public ICompilerExtension > > { > > }; > > > > Method #2 > > > > public class INicksWixExtension : > > public IWixExtensionBase > > { > > private: > > ICompilerExtension m_cCompilerExtension; > > }; > > > > Both methods wuold have to support a generic method of querying the > > extension to see what it supports which would retrun a this pointer > > cast as the appropriate type if supported in method 1, or the pointer > > to the internal member in method 2. > > > > On 11/17/05, Derek Cicerone <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > That's a good point - I should have also mentioned that alternative. I > > > believe the non-interface solution is a bit cleaner because it allows us > to > > > keep the code for each extension in its own class while having the > advantage > > > of the appearance of a single class being visible to the user so that > they > > > can run the different commands as you illustrated below. > > > > > > > > > > > > To summarize, with interfaces: > > > > > > - all extension methods go into one central class that > implements > > > the various interfaces > > > > > > - user can specify this class as the extension for all wix > tools > > > > > > - individual tool extensions (or at least their exposed entry > > > points) are all in one main class like ScaExtension. > > > > > > > > > > > > Without interface: > > > > > > - one extension class implements WixExtension, which then > > > optionally contains references to the individual tool extension class > > > > > > - user can specify this class as the extension for all wix > tools > > > > > > - individual tool extensions remain isolated in classes like > > > ScaCompilerExtension, ScaDecompilerExtension, etc. > > > > > > > > > > > > Derek > > > > > > > > > > > > ________________________________ > > > > > > > > > From: Rob Mensching [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, November 17, 2005 9:24 AM > > > To: [EMAIL PROTECTED]; 'WiX-devs' > > > Subject: RE: [WiX-devs] rfc: re-architect wix extensions > > > > > > > > > > > > > > > What about the option where there is an interface for each Extension > type > > > that a single class could implement. So you could do: > > > > > > > > > > > > candle.exe -ext "extension.dll,ExtensionClass" > > > > > > light.exe -ext "extension.dll,ExtensionClass" > > > > > > dark.exe -ext "extension.dll,ExtensionClass" > > > > > > > > > > > > That ExtensionClass could then implement the ICompilerExtension, > > > IBinderExtension, ITableDefinitionColleciton, IDecompilerExtension. Are > the > > > significant benefits of one method over the other? > > > > > > > > > > > > ________________________________ > > > > > > > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of > > > Derek Cicerone > > > Sent: Wednesday, November 16, 2005 12:22 PM > > > To: 'WiX-devs' > > > Subject: [WiX-devs] rfc: re-architect wix extensions > > > > > > > > > > > > Hi, > > > > > > I'm currently working on supporting decompiler extensions > (which > > > would basically allow someone to create an extension for the decompiler > that > > > would allow custom tables to be converted back into wix authoring). > This > > > will complete the round-tripping of wxs -> msi -> wxs again. > > > > > > > > > > > > Currently we have several wix extensions: > > > > > > - PreprocessorExtension > > > > > > - CompilerExtension > > > > > > - SchemaExtension (its implemented by the CompilerExtension) > > > > > > - BinderExtension > > > > > > - DecompilerExtension > > > > > > > > > > > > Right now, in order to use a Preprocessor extension as well as a > compiler > > > extension, two different -ext options must be passed to candle, like > this: > > > > > > -ext "extention.dll, PreprocessorExtensionClass" -ext "extension.dll, > > > CompilerExtensionClass" > > > > > > > > > > > > This is not too bad because most extensions currently only implement the > > > compiler extension. However, now that we'll have a decompiler extension > > > things get kinda hairy because the decompiler extension must also > implement > > > SchemaExtension (to get the table definitions) and requires the user to > know > > > the two different classes to use within the extension for the compiler > and > > > decompiler respectively. > > > > > > > > > > > > I'd like to propose creating a new WixExtension class to be the main > entry > > > class for all extensions. This class would basically be an abstract > class > > > with properties that would return a PreprocessorExtension, > > > CompilerExtension, etc. if an extension overrides the value to provide > the > > > specific extension class. This class would also contain information > common > > > to multiple extensions like the TableDefinitions. > > > > > > > > > > > > Here's an idea of what it would look like (this is pseudo code): > > > > > > > > > > > > class WixExtension > > > > > > { > > > > > > public virtual CompilerExtension CompilerExtension > > > > > > { > > > > > > get { return null; } > > > > > > } > > > > > > > > > > > > public virtual DecompilerExtension DecompilerExtension > > > > > > { > > > > > > get { return null; } > > > > > > } > > > > > > > > > > > > public virtual TableDefinitionCollection TableDefinitions > > > > > > { > > > > > > get { return null; } > > > > > > } > > > > > > } > > > > > > > > > > > > If we do the proposed changes, since this will break backwards > > > compatibility, I'll also be modifying the CompilerExtension to add the > > > suggested extra optional attributes in the ParseElement method (please > see > > > earlier email). If anyone has any suggestions for other breaking > changes > > > needed for the extension model, this would be a good time to bring them > up J > > > > > > > > > > > > Thanks, > > > > > > Derek > > > > ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click _______________________________________________ WiX-devs mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wix-devs
