[MSEide-MSEgui-talk] some opinions
(Copied from the FPC mailing list where it had erroneously been posted) IMHO this theme is complex enough to start another mailing list instead of discussion it here. There already has been a (IMHO very interesting) discussion in the "German Lazarus forum" that in fact does have an "mse" section for such issues. For me, there were some some discussion results that seem to be seem worth noticing (OS some are just my opinions ) - Martin wants to beat the compiler speed of D7, which he esteems to be 10 times that of fpc. Good luck ! - IMHO, the archs supported should include X32, X64, ARM32, and ARM64 - IMHO, the OSes supported should include Windows (Desktop) and Linux. (Android would be nice but how to do this ?) - There has been a vivid discussion on Unicode support. For me, the results are: . - There should be no string type (out of the box) called "String" or ANSIString or "UnicodeString" (the user can add a "Type" statement if he wants such.) String types should be given "honest names. . - (Rather) decent Unicode handling can only be done with "code aware Strings", which Martin does not want to implement. This of course makes mseLang not really "Unicode aware", which is not a severe problem to most potential users, and in many cases better than not doing Unicode at all. . - For optimum practical use the language should have a (raw) "ByteString" type and a "UTF16String" type that hold exactly the named information. . - The appropriate Character Types of course are "Byte" and "UTF16Char" . - ByteStrings are not printable and there is no auto-conversion . - printable information always is in UTF16Strings. . - The string index (including pos(), ...) is counted in (16 bit) codewords. There is a decent documentation that shows the implications regarding Codepoints > 2^15 and "composed" printable characters. .- String (and array) indexes always count from Zero (neither base 1 (Strings) nor Base whatever Arrays). I vote for adding Syntax for parallel processing (similar to "parallel loop" and "future" in Prism) but this of course is a future nice to have add-on. have fun, -Michael -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
[MSEide-MSEgui-talk] some opinions
(Copied from the FPC mailing list where it had erroneously been posted) IMHO this theme is complex enough to start another mailing list instead of discussion it here. There already has been a (IMHO very interesting) discussion in the "German Lazarus forum" that in fact does have an "mse" section for such issues. For me, there were some some discussion results that seem to be seem worth noticing (OS some are just my opinions ) - Martin wants to beat the compiler speed of D7, which he esteems to be 10 times that of fpc. Good luck ! - IMHO, the archs supported should include X32, X64, ARM32, and ARM64 - IMHO, the OSes supported should include Windows (Desktop) and Linux. (Android would be nice but how to do this ?) - There has been a vivid discussion on Unicode support. For me, the results are: . - There should be no string type (out of the box) called "String" or ANSIString or "UnicodeString" (the user can add a "Type" statement if he wants such.) String types should be given "honest names. . - (Rather) decent Unicode handling can only be done with "code aware Strings", which Martin does not want to implement. This of course makes mseLang not really "Unicode aware", which is not a severe problem to most potential users, and in many cases better than not doing Unicode at all. . - For optimum practical use the language should have a (raw) "ByteString" type and a "UTF16String" type that hold exactly the named information. . - The appropriate Character Types of course are "Byte" and "UTF16Char" . - ByteStrings are not printable and there is no auto-conversion . - printable information always is in UTF16Strings. . - The string index (including pos(), ...) is counted in (16 bit) codewords. There is a decent documentation that shows the implications regarding Codepoints > 2^15 and "composed" printable characters. .- String (and array) indexes always count from Zero (neither base 1 (Strings) nor Base whatever Arrays). I vote for adding Syntax for parallel processing (similar to "parallel loop" and "future" in Prism) but this of course is a future nice to have add-on. have fun, -Michael -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] some opinions
Probably needs a wider discussion & even flaming debates - on "FreePascal.Ru" etc... -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] some opinions
On 11/06/2013 12:57 PM, Ivanko B wrote: > Probably needs a wider discussion & even flaming debates - on > "FreePascal.Ru" etc... We are not discussing free Pascal here, so I don't get the meaning of this ?!?!? -Michael -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] some opinions
On Wednesday 06 November 2013 11:27:58 Michael Schnell wrote: [...] strings It is planned to implement bytestring, bytestring[], string8, string16 and string32. string8 is utf-8 encoded, string16 utf-16, string32 ucs4. string8, string16 and string32 are assignment compatible, index is code unit not code point!. msestring = string16. bytestring can hold any encoding or binary data. There must be a possibility to define the encoding of string and character constants at compiletime for the assignment to bytestring. Martin -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] some opinions
I vote for adding Syntax for parallel processing == It can mainly be useful for parallel-aware languages like Haskell (which prevents form creating state-machine applications badly compatible with paralleizing ). -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] some opinions
On 11/06/2013 01:40 PM, Martin Schreiber wrote: > On Wednesday 06 November 2013 11:27:58 Michael Schnell wrote: > > [...] strings > > It is planned to implement bytestring, bytestring[], string8, > string16 and string32. > string8 is utf-8 encoded, string16 utf-16, string32 ucs4. string8, string16 > and string32 are assignment compatible, OK. > index is code unit not code point!. Supposedly for all string types. (Same as in all Delphi languages I know). Code point indexing would force horrible performance and handling of composed codepoints is not appropriate at all. > msestring = string16. > bytestring can hold any encoding or binary data. There must be a possibility > to define the encoding of string and character constants at compiletime for > the assignment to bytestring. IMHO any not perfectly obvious "automatic" conversion asks for confusion. So (provided your encoding law above) I would not allow for bytestring to be assigned to of from any encoded string. here there user should explicitly call a converter function in the RTL. -Michael -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] some opinions
On 11/06/2013 01:45 PM, Ivanko B wrote: > I vote for adding Syntax for parallel processing > == > It can mainly be useful for parallel-aware languages like Haskell > (which prevents form creating state-machine applications badly > compatible with paralleizing ). > Did you ever take a look at the implementation in Prism ? -Michael -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] some opinions
On Wednesday 06 November 2013 13:08:42 Michael Schnell wrote: > On 11/06/2013 12:57 PM, Ivanko B wrote: > > Probably needs a wider discussion & even flaming debates - on > > "FreePascal.Ru" etc... > > We are not discussing free Pascal here, so I don't get the meaning of > this ?!?!? > Folks of freepascal.ru are open minded people, more open minded than people on fpc-pascal and lazarusforum.de. ;-) Sad that we have the language barrier. Martin -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] some opinions
On 11/06/2013 01:45 PM, Ivanko B wrote: > It can mainly be useful for parallel-aware languages like Haskell > (which prevents form creating state-machine applications badly > compatible with paralleizing ). BTW.: parallel loop is just the most useful construction for parallelism (improving performance for stuff like Vector and Matrix operations). multiple instances of the same code are executed by multiple cores. Of course in a similar way also parallel execution of different code snippets can be implemented, making the language a "parallel-aware language". -Michael -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] some opinions
Of course in a similar way also parallel execution of different code snippets can be implemented, making the language a "parallel-aware language". There's also the conception of "pure function" - which mean such function doesn't use & doesn't change any out-of-function variables thus can safely run in multiple instances. Haskell enforces its functions to be "pure" the unless serve special global interface (so named "monads" ) . -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] some opinions
On 11/06/2013 01:40 PM, Martin Schreiber wrote: > string8, string16 and string32. > string8 is utf-8 encoded, string16 utf-16, string32 ucs4. This ask for three versions of RTL provided classes like TStringlist (and in fact TStrings) , so that the user who decides to use one of the three throughout his program does not suffer from necessary conversions. I doubt that there is a decent way to have the compiler decide which class to use. If multiple explicit classes are not to be used in all places, a kind of automation would be necessary. Either introducing "overloading" of properties according to the type of the assignment partner (I did see such requests in other instances) or adding a kind of encoding aware string type (or "variant String") that "know" that he "is" one of the three. -Michael -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] some opinions
On Thursday 07 November 2013 09:29:29 Michael Schnell wrote: > On 11/06/2013 01:40 PM, Martin Schreiber wrote: > > string8, string16 and string32. > > string8 is utf-8 encoded, string16 utf-16, string32 ucs4. > > This ask for three versions of RTL provided classes like TStringlist > (and in fact TStrings) , so that the user who decides to use one of the > three throughout his program does not suffer from necessary conversions. > MSEgui doesn't use tstringlist, there is a tmsestringdatalist. I assume utf-8 centered toolkits will have a similar class for their use. The RTL will use bytestring for component names and the like so the RTL will have a list class for bytestring only. The RTL will be as small as possible, many functions will be moved to the framework. Martin -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] some opinions
On 11/07/2013 09:42 AM, Martin Schreiber wrote: > > MSEgui doesn't use tstringlist, there is a tmsestringdatalist I don't know msegui well enough to see what this exactly means. Delphi and Lazarus and most programs done with these tools use TStrings all over the place (including, but not limited to TStringList). Here the type used in the Interface of TStrings of course is "String", with the meaning of String varying (non-Unicode Delphi: locale based ANSI 8 Bit, Lazarus: UTF8, Unicode Delphi: UTF16). If mseLang does not have a native (and ambiguous) type "String", but three or more different ones, what should the user do to port his programs ? If "tmsestringdatalist" is to be used completely different than TStringList this will be rather hard. Moreover what about the other siblings of the virtual type "TStrings" ? -Michael -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] some opinions
On Thursday 07 November 2013 12:02:01 Michael Schnell wrote: > > If mseLang does not have a native (and ambiguous) type "String", but > three or more different ones, what should the user do to port his > programs ? > Use the appropriate framework. > If "tmsestringdatalist" is to be used completely different than > TStringList this will be rather hard. > Then make a Delphi framework together with your friends. The MSElang RTL will be the bare minimum. > Moreover what about the other siblings of the virtual type "TStrings" ? > There possibly will be no TStrings in MSElang RTL. Martin -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] some opinions
On 11/07/2013 12:56 PM, Martin Schreiber wrote: > There possibly will be no TStrings in MSElang RTL. As providing TStrings similar to the different types of same in D7, DXE and Lazarus/fpc without creating sever ambiguity is close to impossible, this is OK. If a user wants to port a program he did using one of these Frameworks and he used e.g. TStringList, he thus is required to - do a "Type" statement to make his String variables get the desired mseLang Type (string8, String16 or String32) and - do a "Type" statement to make his Character variables get the desired mseLang Type - implement his own version of TStringList using the mseLang String Type in question. (In fact, I implemented an 8 bit TStringList to use with DXE, by simply stealing the source code from D7, but this of course is only possible, if you in fact own D7, but this usually is provided if you want to port a D7 program). -Michael -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] some opinions
On Thursday 07 November 2013 13:08:07 Michael Schnell wrote: > > If a user wants to port a program he did using one of these Frameworks > and he used e.g. TStringList, he thus is required to > - do a "Type" statement to make his String variables get the desired > mseLang Type (string8, String16 or String32) and > - do a "Type" statement to make his Character variables get the > desired mseLang Type > - implement his own version of TStringList using the mseLang String > Type in question. > Yup, that's the idea. Martin -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] some opinions
My knowledge in this matter is low so just ignore me if I am saying something stupid. Can future unit contains a class variable e.g. Unit Strings; Type TStrings=class; TStringsClass = class of TStrings; var DefaultStringsClass : TStringsClass = TStrings; In user's project code: Program HellowWorld; begin Strings.DefaultClass := TUTFStrings; //in all MSE units, all TStrings instances are created using DefaultClass.Create; //that way, the users' desired TStrings Class will be created. //if some TStrings are created in the initialization section, perhaps, the user can put his own unit as the first unit in the program. In that unit, he can specify the DefaultStringsClass. end; Martin Schreiber wrote: On Thursday 07 November 2013 13:08:07 Michael Schnell wrote: If a user wants to port a program he did using one of these Frameworks and he used e.g. TStringList, he thus is required to - do a "Type" statement to make his String variables get the desired mseLang Type (string8, String16 or String32) and - do a "Type" statement to make his Character variables get the desired mseLang Type - implement his own version of TStringList using the mseLang String Type in question. Yup, that's the idea. Martin -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk - No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3426 / Virus Database: 3222/6816 - Release Date: 11/07/13 -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] some opinions
Dennis, please register here: https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk Thanks. On Friday 08 November 2013 11:36:18 Dennis Poon wrote: > My knowledge in this matter is low so just ignore me if I am saying > something stupid. > > Can future unit contains a class variable e.g. > > Unit Strings; > Type >TStrings=class; > TStringsClass = class of TStrings; > > > var >DefaultStringsClass : TStringsClass = TStrings; > > > > In user's project code: > > Program HellowWorld; > > begin >Strings.DefaultClass := TUTFStrings; > >//in all MSE units, all TStrings instances are created using > DefaultClass.Create; "MSE units means" MSEgui units or MSElang RTL? Martin -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] some opinions
Resend using the correct email address Dennis Poon wrote: My knowledge in this matter is low so just ignore me if I am saying something stupid. Can future unit contains a class variable e.g. Unit Strings; Type TStrings=class; TStringsClass = class of TStrings; var DefaultStringsClass : TStringsClass = TStrings; In user's project code: Program HellowWorld; begin Strings.DefaultClass := TUTFStrings; //in all MSE units, all TStrings instances are created using DefaultClass.Create; //that way, the users' desired TStrings Class will be created. //if some TStrings are created in the initialization section, perhaps, the user can put his own unit as the first unit in the program. In that unit, he can specify the DefaultStringsClass. end; Martin Schreiber wrote: On Thursday 07 November 2013 13:08:07 Michael Schnell wrote: If a user wants to port a program he did using one of these Frameworks and he used e.g. TStringList, he thus is required to - do a "Type" statement to make his String variables get the desired mseLang Type (string8, String16 or String32) and - do a "Type" statement to make his Character variables get the desired mseLang Type - implement his own version of TStringList using the mseLang String Type in question. Yup, that's the idea. Martin -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk -- -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] some opinions
On Friday 08 November 2013 17:19:59 Dennis wrote: > Resend using the correct email address > > Dennis Poon wrote: > > My knowledge in this matter is low so just ignore me if I am saying > > something stupid. > > > > Can future unit contains a class variable e.g. > > > > Unit Strings; > > Type > > TStrings=class; > > TStringsClass = class of TStrings; > > > > > > var > > DefaultStringsClass : TStringsClass = TStrings; > > > > > > > > In user's project code: > > > > Program HellowWorld; > > > > begin > > Strings.DefaultClass := TUTFStrings; > > > > //in all MSE units, all TStrings instances are created using > > DefaultClass.Create; > > //that way, the users' desired TStrings Class will be created. > > "MSE units" means MSEgui units or MSElang RTL? Martin -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
