Re: [fpc-devel] Re: Class field reordering
Am 23.07.2012 06:31 schrieb "Martin Schreiber" : > > On Monday 23 July 2012 00:17:49 Sven Barth wrote: > > > > > > So classes.pp except for TObject is safe? > > > > TObject is defined in unit System... > > > Yes, Iearned it, thanks. :-) I hadn't read the other mails yet that also contained an answer... So, sorry for repeating. :) > So classes unit is safe? As Florian said: currently it is. But if the need arises to introduce compiler dependant code in Classes (for example because of Delphi compatibility) then no one could stop the devs to change this. In sum it would be best to leave all units in the RTL directory alone... Everything in packages on the other hand ;) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
On Sunday 22 July 2012 15:22:44 Hans-Peter Diettrich wrote: > > > Some fields are kept private to ensure that the terms of the contract > > can be met. Making them public/protected means that the terms of the > > contract can be broken by Developer A, when the code of developer B > > depends on the terms being rigorously enforced, and his code can go very > > wrong. > > IMO there exist two use cases for (base) classes: by end users and by > component writers. Both have different goals and problems, which rarely > can be covered by an single set of properties. When an end-user never > should be allowed to write into some field, a developer may have reasons > to do so. > Exactly. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
On Monday 23 July 2012 00:17:49 Sven Barth wrote: > > > > So classes.pp except for TObject is safe? > > TObject is defined in unit System... > Yes, Iearned it, thanks. :-) So classes unit is safe? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MoveChars - docs.embarcadero.com ...
2012/7/22, Hans-Peter Diettrich : > silvioprog schrieb: > >> I could easily do this using "copy", but I'm trying (without success) >> to do this at low level. > > ...where you get what you asked for ;-) :) > Why do you want to do things at low level, which can be done easily on > high level? > > DoDi Is only in a specific case... I'm creating some useful functions for working with CGI (I'm extracting some ideas from PHP). -- Silvio Clécio My public projects - github.com/silvioprog ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
On 22 July 2012 10:09, Martin Schreiber wrote: > I don't dare to ask for changes so cracker classes were a workaround without > to bother FPC team. I sure have had my uphill battles with the FPC team [and not all turned out as I pleased] - but asking the FPC team for a change must still be the first step. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
Hi, On 22 July 2012 07:14, Ivanko B wrote: > private > prorerty Private1: integer read fldPrivate1 write fldPrivate1; > prorerty Private2: integer read fldPrivate2 write fldPrivate2; > protected > prorerty Private1relaxed: integer read fldPrivate1 write fldPrivate1; > > Then MSEgui/FPgui may rely on Private1relaxed insted of fldPrivate1+cracker. I'm sorry Ivanko, but that defeats the whole point of well designed classes and hierarchy. As Michael mentioned - if good reason can be given why a specific private field needs to be accessed, then sure, it should be moved to protected or some property added. The FPC team was accommodating with me in this regard in the past, so I can't see why they would treat Martin any different. Martin simply needs to take them case by case - instead of littering his framework with "cracker" classes, and never raising the issues with the FPC team. Yes, now it is more work for Martin [having having many "cracker" classes implemented], but he should have spoken sooner. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MoveChars - docs.embarcadero.com ...
silvioprog schrieb: I could easily do this using "copy", but I'm trying (without success) to do this at low level. ...where you get what you asked for ;-) Why do you want to do things at low level, which can be done easily on high level? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
Am 22.07.2012 13:18 schrieb "Martin Schreiber" : > > On Sunday 22 July 2012 12:53:43 Jonas Maebe wrote: > > > > I don't think it's the best. I'm also quite sure it will require more work > > from you in the long run, keeping them up to date and merging bug fixes and > > new features from FPC back into your fork. > > > I doubt it, the experience shows the opposite. :-) > > > > AFAIK TObject is the only class which depends on compiler magic? Are > > > there other classes which can not be duplicated? > > > > Pretty much anything in the system and dialect units (objpas, macpas, objc, > > iso7185) is/can be(come) tightly bound to the compiler. The rest should be > > safe. > > > So classes.pp except for TObject is safe? TObject is defined in unit System... Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
Michael Van Canneyt schrieb: The base classes expose a well-defined API. This API is a contract you make with the developers of descendent classes. Which you don't know when designing a base class. Some fields are kept private to ensure that the terms of the contract can be met. Making them public/protected means that the terms of the contract can be broken by Developer A, when the code of developer B depends on the terms being rigorously enforced, and his code can go very wrong. IMO there exist two use cases for (base) classes: by end users and by component writers. Both have different goals and problems, which rarely can be covered by an single set of properties. When an end-user never should be allowed to write into some field, a developer may have reasons to do so. This is of course not so for all private fields, which is why I ask for reasons, so I can decide for each field what can or cannot be done. The more I think about these problems, the more I see class helpers as the natural extension of the language, that allows to implement extensions which have not been foreseen by the class designers. At the risk of the implementors and users, of course. And, if possible, alternative solutions will be presented if they can be found. But for that, I need to know in detail what the problem is in the first place. See above. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
Sven Barth schrieb: >>Should FPC provide a way to access private fields from any other code? > > > Like recent Delphi versions allow by extended RTTI? > FPC will support extended RTTI sooner or later as well. Hopefully with better means to disable it. > Finally class helpers could solve the problem as well, the cleanest solution IMO. While they would be the cleanest solution they won't work as they can only go as deep as (strict) protected (which I still not think was a good by Borland as public/published should have been enough...) Public and published members are accessible already without class helpers. This model would turn class helpers into pure syntactic sugar. But allowing access to private members would not break Delphi compatibility, Delphi code still would compile with FPC. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
Il 22/07/2012 23:15, Marco van de Voort ha scritto: In our previous episode, Florian Kl?mpfl said: Then "friend" classes as C++ offers and wait for this feature were implemented before proceeding with the optimization :) I never saw a C++ class pretending to be somebodies friend. iirc friend classes must be defined in the class which elements shall be access. So C++ like friend classes would help exactly nothing (iirc). Indeed, and in our case those friends list would be in precompiled code. As far as Guiliano's suggestion goes, then I rather use a cmdline option for that (when compiled with that option it is allows to access private fields), rather than syntax. (but I don't know if the PPU format actually contains enough info to access private fields, so this is probably not easy). A command line option would make *all* private fields of *all* objects fully visible. A different class definition would make visible just a few selected classes. It makes quite a difference. But since it is apparently not worth discussing individual cases over, IMHO that means it is not worth compiler changes either. There's an issue which isn't individual but general. Free software means having the freedom of using it however you see fit for your application. This applies to fpc itself, and to fpc based tools, like Lazarus, FPGui, MSEide, MSEgui etc. If fpc offered a way to provide a higher degree of freedom, it would be a general improvement of fpc. If it were done properly it could keep all the advantages of stable guaranteed API's with the flexibility required by a large number of individual cases, which, taken one by one, would be almost impossible to cope with. Taken as a group they make a general case, worth considering. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
In our previous episode, Florian Kl?mpfl said: > > Then "friend" classes as C++ offers and wait for this feature were > > implemented before proceeding with the optimization :) > > > > I never saw a C++ class pretending to be somebodies friend. iirc friend > classes must be defined in the class which elements shall be access. So > C++ like friend classes would help exactly nothing (iirc). Indeed, and in our case those friends list would be in precompiled code. As far as Guiliano's suggestion goes, then I rather use a cmdline option for that (when compiled with that option it is allows to access private fields), rather than syntax. (but I don't know if the PPU format actually contains enough info to access private fields, so this is probably not easy). But since it is apparently not worth discussing individual cases over, IMHO that means it is not worth compiler changes either. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
Am 22.07.2012 23:02, schrieb Ivanko B: > Then "friend" classes as C++ offers and wait for this feature were > implemented before proceeding with the optimization :) > I never saw a C++ class pretending to be somebodies friend. iirc friend classes must be defined in the class which elements shall be access. So C++ like friend classes would help exactly nothing (iirc). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
Then "friend" classes as C++ offers and wait for this feature were implemented before proceeding with the optimization :) 2012/7/22, Giuliano Colla : > Il 22/07/2012 10:39, Michael Van Canneyt ha scritto: >> >> >> On Sat, 21 Jul 2012, Florian Klämpfl wrote: >> >>> Am 21.07.2012 23:06, schrieb Ivanko B: No, just reorder the fields so that they can be properly $IFDEFed as protected for nonLAZARUS and left (private) as is otherwise. >>> >>> Why should lazarus people have less chances to mess with private fields? >>> Either we make them public for all or for nobody. Of course, then >>> everybody has to take care of the fact that users might mess with these >>> fields. >> >> Which is exactly why we will not do this. >> >> The base classes expose a well-defined API. This API is a contract you >> make with the developers of descendent classes. >> >> Some fields are kept private to ensure that the terms of the contract >> can be met. Making them public/protected means that the terms of the >> contract can be broken by Developer A, when the code of developer B >> depends on the terms being rigorously enforced, and his code can go >> very wrong. >> >> This is of course not so for all private fields, which is why I ask >> for reasons, so I can decide for each field what can or cannot be done. >> > There are excellent reasons not to expose private fields. What must be > opaque and what must be visible to end users are designers decisions > which involve the capability of providing new implementation without > breaking existing code, take into account multiplatform needs, consider > the planned improvements, etc. etc. > > On the other side there are sometimes good and sound reasons for someone > to break this rule, at his own risk, of course. It may be to quickly fix > a bug, to provide an extra feature by reusing an existing object instead > of rewriting a lot of code, etc. Of course this is a practice not to be > recommended in general, but it occurs. And in many cases it is connected > to specific needs which aren't of general interest, making the effort of > supporting them hardly worthwhile. > > IMHO a clean solution can be found at language level: if I declare > > TMyclass = class(TWhatever) > > then I just get the degree of visibility that the class designer has > decided. > > But if I declare (just an example, a better keyword can be found) > TMyclass = subclass(TWhatever) > then I get full visibility, all the private fields of TWhatever become > just protected in TMyclass, and of course, I'm on my own. The designer > is not bound to any contract, because I have explicitly decided to run > the risk. > > This solution would allow mainstream designers to keep fields visibility > to what they deem to be a safe level in general, without making it > impossible to non mainstream designers to provide features which aren't > considered of general interest. > > Just my 5 cents. > > Giuliano > > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MoveChars - docs.embarcadero.com ...
2012/7/22, Jonas Maebe : > On 22 Jul 2012, at 20:18, silvioprog wrote: > >> 2012/7/22, Jonas Maebe : >>> >>> On 22 Jul 2012, at 04:54, silvioprog wrote: >>> There MoveChars* function (or similar) native on Free Pascal? (*) - http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/delphivclwin32/System_MoveChars.html >>> >>> As far as I can tell, >>> >>> MoveChars(Source,Dest,Length); >>> >>> is exactly the same as >>> >>> Move(Source,Dest,Length*2); >> >> Hm... I think that MoveChars copy a string to another string, but >> maintaining the contents of the second string (I'm without delphi for >> test it). > > MoveChars just moves data. It has no special support for strings or anything > else. See the example code on the Embarcadero site. > >> So, I'll try to explain my problem ... >> >> I am needing to move a string to another string, eg: >> >> var >> d, s: string; >> begin >> d := 'the on the table'; >> s := 'books '; >> SetLength(d, Length(d) + Length(s)); >> Move(s, d[4], Length(s)); > > This moves the contents of the string pointer (I suppose you are in a mode > where string=ansistring), you have to use s[1] instead. > >> writeln(d); // the result should be 'the books on the table', but I >> get 'the|?S |?e table ?' > > What you want is > > var > d, s: string; > begin > d := 'the on the table'; > s := 'books '; > insert(s,d,4); > writeln(d); > >> end; >> I could easily do this using "copy", but I'm trying (without success) >> to do this at low level. > > I would strongly recommend against it. You'll mainly run into problems by > combining reference counted data and low level routines. The RTL versions > already use the low level routines in the correct ways. > > > Jonas I'll use Insert, because now I can see what is really recommended. :) Thank you again Jonas! -- Silvio Clécio My public projects - github.com/silvioprog ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MoveChars - docs.embarcadero.com ...
On 22 Jul 2012, at 20:18, silvioprog wrote: > 2012/7/22, Jonas Maebe : >> >> On 22 Jul 2012, at 04:54, silvioprog wrote: >> >>> There MoveChars* function (or similar) native on Free Pascal? >>> >>> (*) - >>> http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/delphivclwin32/System_MoveChars.html >> >> As far as I can tell, >> >> MoveChars(Source,Dest,Length); >> >> is exactly the same as >> >> Move(Source,Dest,Length*2); > > Hm... I think that MoveChars copy a string to another string, but > maintaining the contents of the second string (I'm without delphi for > test it). MoveChars just moves data. It has no special support for strings or anything else. See the example code on the Embarcadero site. > So, I'll try to explain my problem ... > > I am needing to move a string to another string, eg: > > var > d, s: string; > begin > d := 'the on the table'; > s := 'books '; > SetLength(d, Length(d) + Length(s)); > Move(s, d[4], Length(s)); This moves the contents of the string pointer (I suppose you are in a mode where string=ansistring), you have to use s[1] instead. > writeln(d); // the result should be 'the books on the table', but I > get 'the|?S |?e table ?' What you want is var d, s: string; begin d := 'the on the table'; s := 'books '; insert(s,d,4); writeln(d); > end; > I could easily do this using "copy", but I'm trying (without success) > to do this at low level. I would strongly recommend against it. You'll mainly run into problems by combining reference counted data and low level routines. The RTL versions already use the low level routines in the correct ways. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MoveChars - docs.embarcadero.com ...
2012/7/22, silvioprog : [...] > to do this at low level. ... in low level ... -- Silvio Clécio My public projects - github.com/silvioprog ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MoveChars - docs.embarcadero.com ...
2012/7/22, Jonas Maebe : > > On 22 Jul 2012, at 04:54, silvioprog wrote: > >> There MoveChars* function (or similar) native on Free Pascal? >> >> (*) - >> http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/delphivclwin32/System_MoveChars.html > > As far as I can tell, > > MoveChars(Source,Dest,Length); > > is exactly the same as > > Move(Source,Dest,Length*2); > > > Jonas Hm... I think that MoveChars copy a string to another string, but maintaining the contents of the second string (I'm without delphi for test it). So, I'll try to explain my problem ... I am needing to move a string to another string, eg: var d, s: string; begin d := 'the on the table'; s := 'books '; SetLength(d, Length(d) + Length(s)); Move(s, d[4], Length(s)); writeln(d); // the result should be 'the books on the table', but I get 'the|?S |?e table ?' end; I could easily do this using "copy", but I'm trying (without success) to do this at low level. Thank you Jonas! :) -- Silvio Clécio My public projects - github.com/silvioprog ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
Il 22/07/2012 10:39, Michael Van Canneyt ha scritto: On Sat, 21 Jul 2012, Florian Klämpfl wrote: Am 21.07.2012 23:06, schrieb Ivanko B: No, just reorder the fields so that they can be properly $IFDEFed as protected for nonLAZARUS and left (private) as is otherwise. Why should lazarus people have less chances to mess with private fields? Either we make them public for all or for nobody. Of course, then everybody has to take care of the fact that users might mess with these fields. Which is exactly why we will not do this. The base classes expose a well-defined API. This API is a contract you make with the developers of descendent classes. Some fields are kept private to ensure that the terms of the contract can be met. Making them public/protected means that the terms of the contract can be broken by Developer A, when the code of developer B depends on the terms being rigorously enforced, and his code can go very wrong. This is of course not so for all private fields, which is why I ask for reasons, so I can decide for each field what can or cannot be done. There are excellent reasons not to expose private fields. What must be opaque and what must be visible to end users are designers decisions which involve the capability of providing new implementation without breaking existing code, take into account multiplatform needs, consider the planned improvements, etc. etc. On the other side there are sometimes good and sound reasons for someone to break this rule, at his own risk, of course. It may be to quickly fix a bug, to provide an extra feature by reusing an existing object instead of rewriting a lot of code, etc. Of course this is a practice not to be recommended in general, but it occurs. And in many cases it is connected to specific needs which aren't of general interest, making the effort of supporting them hardly worthwhile. IMHO a clean solution can be found at language level: if I declare TMyclass = class(TWhatever) then I just get the degree of visibility that the class designer has decided. But if I declare (just an example, a better keyword can be found) TMyclass = subclass(TWhatever) then I get full visibility, all the private fields of TWhatever become just protected in TMyclass, and of course, I'm on my own. The designer is not bound to any contract, because I have explicitly decided to run the risk. This solution would allow mainstream designers to keep fields visibility to what they deem to be a safe level in general, without making it impossible to non mainstream designers to provide features which aren't considered of general interest. Just my 5 cents. Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
Am 22.07.2012 14:06, schrieb Martin Schreiber: On Sunday 22 July 2012 13:53:28 Florian Klaempfl wrote: So classes.pp except for TObject is safe? Afaik yes. Exception is in sysutils (magic too ?), tobject is in objpas. Ah, yes. So whole classes unit is independent from compiler. Super. :-) I wouldn't bet on it though. Why not? There is no guarantee. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
On Sunday 22 July 2012 13:53:28 Florian Klaempfl wrote: > >>> So classes.pp except for TObject is safe? > >> > >> Afaik yes. Exception is in sysutils (magic too ?), tobject is in objpas. > > > > Ah, yes. So whole classes unit is independent from compiler. Super. :-) > > I wouldn't bet on it though. > Why not? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
Am 22.07.2012 13:44, schrieb Martin Schreiber: On Sunday 22 July 2012 13:23:50 Marco van de Voort wrote: In our previous episode, Martin Schreiber said: I don't think it's the best. I'm also quite sure it will require more work from you in the long run, keeping them up to date and merging bug fixes and new features from FPC back into your fork. I doubt it, the experience shows the opposite. :-) AFAIK TObject is the only class which depends on compiler magic? Are there other classes which can not be duplicated? Pretty much anything in the system and dialect units (objpas, macpas, objc, iso7185) is/can be(come) tightly bound to the compiler. The rest should be safe. So classes.pp except for TObject is safe? Afaik yes. Exception is in sysutils (magic too ?), tobject is in objpas. Ah, yes. So whole classes unit is independent from compiler. Super. :-) I wouldn't bet on it though. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
On Sunday 22 July 2012 13:23:50 Marco van de Voort wrote: > In our previous episode, Martin Schreiber said: > > > I don't think it's the best. I'm also quite sure it will require more > > > work from you in the long run, keeping them up to date and merging bug > > > fixes and new features from FPC back into your fork. > > > > I doubt it, the experience shows the opposite. :-) > > > > > > AFAIK TObject is the only class which depends on compiler magic? Are > > > > there other classes which can not be duplicated? > > > > > > Pretty much anything in the system and dialect units (objpas, macpas, > > > objc, iso7185) is/can be(come) tightly bound to the compiler. The rest > > > should be safe. > > > > So classes.pp except for TObject is safe? > > Afaik yes. Exception is in sysutils (magic too ?), tobject is in objpas. > Ah, yes. So whole classes unit is independent from compiler. Super. :-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
Some fields are kept private to ensure that the terms of the contract can be met. Making them public/protected means that the terms of the contract can be broken by Developer A, when the code of developer B depends on the terms being rigorously enforced, and his code can go very wrong. Then additional protected properties exposing private fields can also be a part of these contracts - as a agreed exclusions to the contracts. 2012/7/22, Ivanko B : > A (global) compiler option "treat private as protected" might be > another solution. > > Same and less flexible than the {$ifdef nonLazarus} solution. > > What are the numbers of the issues worked around by the crackers? > === > The exact number isn't very important. For instance, Martin, Graeme... > always report all bugs found by them but still need the ability to > proceed without waiting for the bugs gets fixed [ sometimes because > guys like me & customers insist on it]. > Forking is bad since squeezes the base of advanced users (bug reveals, > good proposals & patches, ..) of the forked feature of mainstream > project. > > > 2012/7/22, Sven Barth : >> Am 22.07.2012 09:24 schrieb "Hans-Peter Diettrich" >> : >>> >>> Martin schrieb: >>> On 21/07/2012 16:55, Ivanko B wrote: > > The problem now is that cracker classes can't be used in future > anymore > because of the new class field ordering optimisation, so I dared to >> ask. > > So, is it possible to design the new feature in such way that to have > an option to proceed using cracker classes ? > But the whole discussion comes down to one other simple question. >> Including the above, the whole discussion is about: Should FPC provide a way to access private fields from any other code? >>> >>> >>> Like recent Delphi versions allow by extended RTTI? >>> >> >> FPC will support extended RTTI sooner or later as well. >> >>> Finally class helpers could solve the problem as well, the cleanest >> solution IMO. >> >> While they would be the cleanest solution they won't work as they can >> only >> go as deep as (strict) protected (which I still not think was a good by >> Borland as public/published should have been enough...) >> >> Regards, >> Sven >> > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
In our previous episode, Martin Schreiber said: > > I don't think it's the best. I'm also quite sure it will require more work > > from you in the long run, keeping them up to date and merging bug fixes and > > new features from FPC back into your fork. > > > I doubt it, the experience shows the opposite. :-) > > > > AFAIK TObject is the only class which depends on compiler magic? Are > > > there other classes which can not be duplicated? > > > > Pretty much anything in the system and dialect units (objpas, macpas, objc, > > iso7185) is/can be(come) tightly bound to the compiler. The rest should be > > safe. > > > So classes.pp except for TObject is safe? Afaik yes. Exception is in sysutils (magic too ?), tobject is in objpas. The only thing to watch is the {$M+} around TPersistent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
On 22 Jul 2012, at 13:11, Joost van der Sluis wrote: > On Sun, 2012-07-22 at 12:53 +0200, Jonas Maebe wrote: >> Pretty much anything in the system and dialect units (objpas, macpas, objc, >> iso7185) is/can be(come) tightly bound to the compiler. The rest should be >> safe. > > There are more, like typinfo. In fact you could copy that one, but when > the underlying rtti-information generated by the compiler changes... True. Looking more closely, there's also "fpintres", "fpextres", "softfpu" and maybe "variants". Still, it's a finite and not that extensive list. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
On Sunday 22 July 2012 12:53:43 Jonas Maebe wrote: > > I don't think it's the best. I'm also quite sure it will require more work > from you in the long run, keeping them up to date and merging bug fixes and > new features from FPC back into your fork. > I doubt it, the experience shows the opposite. :-) > > AFAIK TObject is the only class which depends on compiler magic? Are > > there other classes which can not be duplicated? > > Pretty much anything in the system and dialect units (objpas, macpas, objc, > iso7185) is/can be(come) tightly bound to the compiler. The rest should be > safe. > So classes.pp except for TObject is safe? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
On Sun, 2012-07-22 at 12:53 +0200, Jonas Maebe wrote: > On 22 Jul 2012, at 12:40, Martin Schreiber wrote: > > AFAIK TObject is the only class which depends on compiler magic? Are there > > other classes which can not be duplicated? > > Pretty much anything in the system and dialect units (objpas, macpas, objc, > iso7185) is/can be(come) tightly bound to the compiler. The rest should be > safe. There are more, like typinfo. In fact you could copy that one, but when the underlying rtti-information generated by the compiler changes... Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
On Sun, 2012-07-22 at 12:40 +0200, Martin Schreiber wrote: > On Sunday 22 July 2012 12:06:31 Jonas Maebe wrote: > The situation here is especial because I must convince Michael for things > that > is of use for MSEgui only and most likely for no use in Lazarus or > contradicts his design principles. No, as I understood Michael, you have to convince others that what you want can not be done otherwise. Also, making private fields accessible is not always the only - or best - solutions. So the alternatives also have to be evaluated. By discussing this the framework as a whole can only become better and more flexible, for all users. The msegui/lazarus points have nothing to do with it. Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
On 22 Jul 2012, at 12:40, Martin Schreiber wrote: > The situation here is especial because I must convince Michael for things > that > is of use for MSEgui only and most likely for no use in Lazarus or > contradicts his design principles. I don't think "Lazarus doesn't need it" would be a valid argument to reject a proposed change. As to the design principles: > I learned that this situation is > unwinnable so I used mad workarounds with cracker classes instead. > Now I see that even moving private fields to protected is very difficult so I > will search for other solutions. The problem with making private fields more accessible is similar as with supporting cracking classes: it makes it much harder to change implementation aspects in the future without breaking anything. The whole point of encapsulation is to make it easier to change the implementation as necessary/desirable later on. This requires work to find the right encapsulation abstractions (which can relatively easily be changed in case the implementation is hidden, because then implementation changes won't hurt other uses), but it's the only way that is maintainable in the long run. > An API compatible MSEgui db.pas and MSEgui specific TComponent, TReader, > TWriter and other dependent classes is probably the best. I don't think it's the best. I'm also quite sure it will require more work from you in the long run, keeping them up to date and merging bug fixes and new features from FPC back into your fork. > AFAIK TObject is the only class which depends on compiler magic? Are there > other classes which can not be duplicated? Pretty much anything in the system and dialect units (objpas, macpas, objc, iso7185) is/can be(come) tightly bound to the compiler. The rest should be safe. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
On Sun, 22 Jul 2012, Jonas Maebe wrote: On 22 Jul 2012, at 11:50, Martin Schreiber wrote: Sorry Michael, I do not trust that the effort is worth the outcome for me. You're really putting us between a rock and a hard place here. It's quite tempting to retort with "the next time I'll just commit my changes and tell people to deal with it, because I do not trust that the effort of discussing them first is worth the outcome for me". Of course explaining yourself and discussing costs time, and of course there are never guarantees about the outcome. That holds for everyone. If you shut out yourself from the discussion a priori, you basically force the other people to either a) be the "bad guys" because they don't take your grievances into account (mainly because they don't know enough about them to sensibly think about them), or b) just give up because they don't want to break other people's code like that And maybe the worst of all: the next time you have a question that requires thinking or discussing, people may be less inclined to spend effort on that because you don't return the same courtesy in the opposite situation. I couldn't have put it better than Jonas and Marco. I can only repeat: please explain, we'll try to find solutions. If you don't trust that, there is nothing more to be said. It works both ways. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
On Sunday 22 July 2012 12:06:31 Jonas Maebe wrote: > On 22 Jul 2012, at 11:50, Martin Schreiber wrote: > > Sorry Michael, I do not trust that the effort is worth the outcome for > > me. > > You're really putting us between a rock and a hard place here. It's quite > tempting to retort with "the next time I'll just commit my changes and tell > people to deal with it, because I do not trust that the effort of > discussing them first is worth the outcome for me". > > Of course explaining yourself and discussing costs time, and of course > there are never guarantees about the outcome. That holds for everyone. If > you shut out yourself from the discussion a priori, you basically force the > other people to either a) be the "bad guys" because they don't take your > grievances into account (mainly because they don't know enough about them > to sensibly think about them), or b) just give up because they don't want > to break other people's code like that > > And maybe the worst of all: the next time you have a question that requires > thinking or discussing, people may be less inclined to spend effort on that > because you don't return the same courtesy in the opposite situation. > I did and will do. The situation here is especial because I must convince Michael for things that is of use for MSEgui only and most likely for no use in Lazarus or contradicts his design principles. I learned that this situation is unwinnable so I used mad workarounds with cracker classes instead. Now I see that even moving private fields to protected is very difficult so I will search for other solutions. An API compatible MSEgui db.pas and MSEgui specific TComponent, TReader, TWriter and other dependent classes is probably the best. AFAIK TObject is the only class which depends on compiler magic? Are there other classes which can not be duplicated? Thanks, Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
So, there're the following solutions which meet the requirements of optimization & not breaking non-mainstream code & no need to custom build FPC: 1) moving related fields from private to protected or even public (makes the current classes structure more vulnerable) 2) creating protected "brother" properties for related private fields ( less appealing than "1)" = people using them knows what they do ) 2012/7/22, Ivanko B : > Alternatives we present are discarded as sub-optimal or not to your liking. > Let me recapitulate: > > 1. You reject my solution for TField. > 2. For TCollection.FItemClass I presented an alternative for your problem. > 3. TParam.Bound turned out not to be a problem at all. > == > True but it relates to old issues, but there may be future issues > (subjects to wait until get fixed) - Martin, Graeme are mainly > bothered by them - whether it'll be possible to fix them in 1..2 days > (customer etc requirements) and in such manner that not to rebuild FPC > at developer's side. > > > 2012/7/22, Ivanko B : >> directive to turn said optimization off >> == >> But everyone wants the optimization ! (sure without breaking >> consequences) >> >> >> 2012/7/22, Ivanko B : >>> Asking for changes to make base classes more flexible is not bothering >>> us. It's a regular part of software development, and in the best case >>> every user of FPC comes out ahead in the end thanks to the resulting >>> changes. >>> >>> Hacking around the type system that results in certain optimizations >>> becoming impossible is annoying, however. And I don't really see a >>> best case outcome in this case, regardless of what is done in the end. >>> == >>> Hmm..it sounds like "Relaxing access rights is a usual deal and why >>> shouldn't we do it again to resolve the contradictions - especially if >>> it turns out to be the only relevant ?" :) >>> >>> >>> 2012/7/22, Jonas Maebe : On 22 Jul 2012, at 11:09, Martin Schreiber wrote: > Which otherwise can't be implemented without changes in FPC or FCL. > I don't dare to ask for changes so cracker classes were a workaround > without > to bother FPC team. Asking for changes to make base classes more flexible is not bothering us. It's a regular part of software development, and in the best case every user of FPC comes out ahead in the end thanks to the resulting changes. Hacking around the type system that results in certain optimizations becoming impossible is annoying, however. And I don't really see a best case outcome in this case, regardless of what is done in the end. Jonas PS: just to make it clear, I haven't committed this optimization yet.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel >>> >> > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MoveChars - docs.embarcadero.com ...
On 22 Jul 2012, at 04:54, silvioprog wrote: > There MoveChars* function (or similar) native on Free Pascal? > > (*) - > http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/delphivclwin32/System_MoveChars.html As far as I can tell, MoveChars(Source,Dest,Length); is exactly the same as Move(Source,Dest,Length*2); Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
On 22 Jul 2012, at 11:50, Martin Schreiber wrote: > Sorry Michael, I do not trust that the effort is worth the outcome for me. You're really putting us between a rock and a hard place here. It's quite tempting to retort with "the next time I'll just commit my changes and tell people to deal with it, because I do not trust that the effort of discussing them first is worth the outcome for me". Of course explaining yourself and discussing costs time, and of course there are never guarantees about the outcome. That holds for everyone. If you shut out yourself from the discussion a priori, you basically force the other people to either a) be the "bad guys" because they don't take your grievances into account (mainly because they don't know enough about them to sensibly think about them), or b) just give up because they don't want to break other people's code like that And maybe the worst of all: the next time you have a question that requires thinking or discussing, people may be less inclined to spend effort on that because you don't return the same courtesy in the opposite situation. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
In our previous episode, Martin Schreiber said: > > >> Martin needs the crackers for some mse* features. > > That's because you don't just ask for changes. > > You ask for your own solutions to be implemented in FPC. > > > I do not ask for my own solutions, I ask to move private FPC class fields and > methods of base classes which are used in different toolkits to protected in > order to make them more flexible without changing any functionality and > because the current workaround with cracker classes may be not possible > anymore in future because of upcoming FPC optimisations. I don't like this as a blanket solution. Individual cases can be discussed, making it a principle means that we have to support even more of the interface (everything that can be reach by hacking the implementation of the moment). > > You must give detailed descriptions of what you think is a problem, > > and be prepared to accept solutions that are maybe not 100% to your liking. > > > > If you are not prepared to accept such solutions, then I cannot help you. > > > Sorry Michael, I do not trust that the effort is worth the outcome for me. Then IMHO you are on your own in finding solutions. We can be reasoned with, but if people don't bother, there is nothing we can do. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
On Sun, 22 Jul 2012, Ivanko B wrote: Alternatives we present are discarded as sub-optimal or not to your liking. Let me recapitulate: 1. You reject my solution for TField. 2. For TCollection.FItemClass I presented an alternative for your problem. 3. TParam.Bound turned out not to be a problem at all. == True but it relates to old issues, but there may be future issues (subjects to wait until get fixed) - Martin, Graeme are mainly bothered by them - whether it'll be possible to fix them in 1..2 days (customer etc requirements) and in such manner that not to rebuild FPC at developer's side. If you find a problem to a bug, you can submit a patch. Martin has frequently done so, so has Graeme. I always thank people for bugs they report or even fix. I do not recall us refusing bug fixes. What Martin currently does is not asking for bug fixes. He requests fundamental changes to the base classes, which he needs to implement some features in the particular way that he chose. That is a completely different story. I can understand his desire to implement new features, which is why I offer to help thinking of solutions. In some harmless cases this solution may well be promoting a field to protected. In others, it will not, for reasons I have explained elsewhere. I judge that on an individual case basis. It is up to him to accept or reject the offered solutions. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
On Sunday 22 July 2012 11:28:22 Michael Van Canneyt wrote: > On Sun, 22 Jul 2012, Martin Schreiber wrote: > > On Sunday 22 July 2012 10:52:33 Michael Van Canneyt wrote: > >>> "Numbers", not count. I want to know which bugs are worked around by > >>> crackers. > >> > >> That's easy: 0 bugs. > > > > Sorry, there where bugs in the past and there probably will be in the > > future. > > There are always bugs. We fix those as soon as we can. > > Florian is talking about bugs you fix with cracker classes. > Me too. > >> Martin needs the crackers for some mse* features. > > > > Which otherwise can't be implemented without changes in FPC or FCL. > > I don't dare to ask for changes so cracker classes were a workaround > > without to bother FPC team. > > That's because you don't just ask for changes. > You ask for your own solutions to be implemented in FPC. > I do not ask for my own solutions, I ask to move private FPC class fields and methods of base classes which are used in different toolkits to protected in order to make them more flexible without changing any functionality and because the current workaround with cracker classes may be not possible anymore in future because of upcoming FPC optimisations. [...] > Cooperation works in 2 directions. I'm willing to think about solutions. > You must give detailed descriptions of what you think is a problem, > and be prepared to accept solutions that are maybe not 100% to your liking. > > If you are not prepared to accept such solutions, then I cannot help you. > Sorry Michael, I do not trust that the effort is worth the outcome for me. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
Alternatives we present are discarded as sub-optimal or not to your liking. Let me recapitulate: 1. You reject my solution for TField. 2. For TCollection.FItemClass I presented an alternative for your problem. 3. TParam.Bound turned out not to be a problem at all. == True but it relates to old issues, but there may be future issues (subjects to wait until get fixed) - Martin, Graeme are mainly bothered by them - whether it'll be possible to fix them in 1..2 days (customer etc requirements) and in such manner that not to rebuild FPC at developer's side. 2012/7/22, Ivanko B : > directive to turn said optimization off > == > But everyone wants the optimization ! (sure without breaking consequences) > > > 2012/7/22, Ivanko B : >> Asking for changes to make base classes more flexible is not bothering >> us. It's a regular part of software development, and in the best case >> every user of FPC comes out ahead in the end thanks to the resulting >> changes. >> >> Hacking around the type system that results in certain optimizations >> becoming impossible is annoying, however. And I don't really see a >> best case outcome in this case, regardless of what is done in the end. >> == >> Hmm..it sounds like "Relaxing access rights is a usual deal and why >> shouldn't we do it again to resolve the contradictions - especially if >> it turns out to be the only relevant ?" :) >> >> >> 2012/7/22, Jonas Maebe : >>> >>> On 22 Jul 2012, at 11:09, Martin Schreiber wrote: >>> Which otherwise can't be implemented without changes in FPC or FCL. I don't dare to ask for changes so cracker classes were a workaround without to bother FPC team. >>> >>> Asking for changes to make base classes more flexible is not bothering >>> us. >>> It's a regular part of software development, and in the best case every >>> user >>> of FPC comes out ahead in the end thanks to the resulting changes. >>> >>> Hacking around the type system that results in certain optimizations >>> becoming impossible is annoying, however. And I don't really see a best >>> case >>> outcome in this case, regardless of what is done in the end. >>> >>> >>> Jonas >>> >>> PS: just to make it clear, I haven't committed this optimization >>> yet.___ >>> fpc-devel maillist - fpc-devel@lists.freepascal.org >>> http://lists.freepascal.org/mailman/listinfo/fpc-devel >>> >> > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
directive to turn said optimization off == But everyone wants the optimization ! (sure without breaking consequences) 2012/7/22, Ivanko B : > Asking for changes to make base classes more flexible is not bothering > us. It's a regular part of software development, and in the best case > every user of FPC comes out ahead in the end thanks to the resulting > changes. > > Hacking around the type system that results in certain optimizations > becoming impossible is annoying, however. And I don't really see a > best case outcome in this case, regardless of what is done in the end. > == > Hmm..it sounds like "Relaxing access rights is a usual deal and why > shouldn't we do it again to resolve the contradictions - especially if > it turns out to be the only relevant ?" :) > > > 2012/7/22, Jonas Maebe : >> >> On 22 Jul 2012, at 11:09, Martin Schreiber wrote: >> >>> Which otherwise can't be implemented without changes in FPC or FCL. >>> I don't dare to ask for changes so cracker classes were a workaround >>> without >>> to bother FPC team. >> >> Asking for changes to make base classes more flexible is not bothering >> us. >> It's a regular part of software development, and in the best case every >> user >> of FPC comes out ahead in the end thanks to the resulting changes. >> >> Hacking around the type system that results in certain optimizations >> becoming impossible is annoying, however. And I don't really see a best >> case >> outcome in this case, regardless of what is done in the end. >> >> >> Jonas >> >> PS: just to make it clear, I haven't committed this optimization >> yet.___ >> fpc-devel maillist - fpc-devel@lists.freepascal.org >> http://lists.freepascal.org/mailman/listinfo/fpc-devel >> > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
Asking for changes to make base classes more flexible is not bothering us. It's a regular part of software development, and in the best case every user of FPC comes out ahead in the end thanks to the resulting changes. Hacking around the type system that results in certain optimizations becoming impossible is annoying, however. And I don't really see a best case outcome in this case, regardless of what is done in the end. == Hmm..it sounds like "Relaxing access rights is a usual deal and why shouldn't we do it again to resolve the contradictions - especially if it turns out to be the only relevant ?" :) 2012/7/22, Jonas Maebe : > > On 22 Jul 2012, at 11:09, Martin Schreiber wrote: > >> Which otherwise can't be implemented without changes in FPC or FCL. >> I don't dare to ask for changes so cracker classes were a workaround >> without >> to bother FPC team. > > Asking for changes to make base classes more flexible is not bothering us. > It's a regular part of software development, and in the best case every user > of FPC comes out ahead in the end thanks to the resulting changes. > > Hacking around the type system that results in certain optimizations > becoming impossible is annoying, however. And I don't really see a best case > outcome in this case, regardless of what is done in the end. > > > Jonas > > PS: just to make it clear, I haven't committed this optimization > yet.___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
In our previous episode, Ivanko B said: > Or an option: > > {$ifdef nonLazarus} > protected > ... > {$else} > private > ... > {$endif} > > Then MSEgui/FPgui/.. may be compiled with "-DnonLazarus" option Requires recompile, and a directive to turn said optimization off would then be better (and not carve up the sources). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
On Sun, 22 Jul 2012, Martin Schreiber wrote: On Sunday 22 July 2012 10:52:33 Michael Van Canneyt wrote: "Numbers", not count. I want to know which bugs are worked around by crackers. That's easy: 0 bugs. Sorry, there where bugs in the past and there probably will be in the future. There are always bugs. We fix those as soon as we can. Florian is talking about bugs you fix with cracker classes. What bug do you solve with the TField stuff ? None. You work around a limitation, yes. But a limitation is not a bug. Martin needs the crackers for some mse* features. Which otherwise can't be implemented without changes in FPC or FCL. I don't dare to ask for changes so cracker classes were a workaround without to bother FPC team. That's because you don't just ask for changes. You ask for your own solutions to be implemented in FPC. Alternatives we present are discarded as sub-optimal or not to your liking. Let me recapitulate: 1. You reject my solution for TField. 2. For TCollection.FItemClass I presented an alternative for your problem. 3. TParam.Bound turned out not to be a problem at all. So, * 1 case which is not a problem. * 2 cases where you have been presented with a solution, but which you chose to reject. You can't blame us for that. As for the TComponent and TStream problem cases, I am still waiting to see what bugs (if any) you want to solve: You failed to give detailed descriptions so far. Cooperation works in 2 directions. I'm willing to think about solutions. You must give detailed descriptions of what you think is a problem, and be prepared to accept solutions that are maybe not 100% to your liking. If you are not prepared to accept such solutions, then I cannot help you. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
On 22 Jul 2012, at 11:09, Martin Schreiber wrote: > Which otherwise can't be implemented without changes in FPC or FCL. > I don't dare to ask for changes so cracker classes were a workaround without > to bother FPC team. Asking for changes to make base classes more flexible is not bothering us. It's a regular part of software development, and in the best case every user of FPC comes out ahead in the end thanks to the resulting changes. Hacking around the type system that results in certain optimizations becoming impossible is annoying, however. And I don't really see a best case outcome in this case, regardless of what is done in the end. Jonas PS: just to make it clear, I haven't committed this optimization yet.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
On Sunday 22 July 2012 10:52:33 Michael Van Canneyt wrote: > > "Numbers", not count. I want to know which bugs are worked around by > > crackers. > > That's easy: 0 bugs. > Sorry, there where bugs in the past and there probably will be in the future. > Martin needs the crackers for some mse* features. > Which otherwise can't be implemented without changes in FPC or FCL. I don't dare to ask for changes so cracker classes were a workaround without to bother FPC team. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
On Sun, 22 Jul 2012, Florian Klämpfl wrote: Am 22.07.2012 10:44, schrieb Ivanko B: A (global) compiler option "treat private as protected" might be another solution. This is no solution but a hack. Same and less flexible than the {$ifdef nonLazarus} solution. What are the numbers of the issues worked around by the crackers? === The exact number isn't very important. "Numbers", not count. I want to know which bugs are worked around by crackers. That's easy: 0 bugs. Martin needs the crackers for some mse* features. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
Am 22.07.2012 10:44, schrieb Ivanko B: > A (global) compiler option "treat private as protected" might be > another solution. This is no solution but a hack. > > Same and less flexible than the {$ifdef nonLazarus} solution. > > What are the numbers of the issues worked around by the crackers? > === > The exact number isn't very important. "Numbers", not count. I want to know which bugs are worked around by crackers. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
A (global) compiler option "treat private as protected" might be another solution. Same and less flexible than the {$ifdef nonLazarus} solution. What are the numbers of the issues worked around by the crackers? === The exact number isn't very important. For instance, Martin, Graeme... always report all bugs found by them but still need the ability to proceed without waiting for the bugs gets fixed [ sometimes because guys like me & customers insist on it]. Forking is bad since squeezes the base of advanced users (bug reveals, good proposals & patches, ..) of the forked feature of mainstream project. 2012/7/22, Sven Barth : > Am 22.07.2012 09:24 schrieb "Hans-Peter Diettrich" : >> >> Martin schrieb: >> >>> On 21/07/2012 16:55, Ivanko B wrote: The problem now is that cracker classes can't be used in future anymore because of the new class field ordering optimisation, so I dared to > ask. >>> >>> So, is it possible to design the new feature in such way that to have an option to proceed using cracker classes ? >>> >>> But the whole discussion comes down to one other simple question. > Including the above, the whole discussion is about: >>> >>>Should FPC provide a way to access private fields from any other >>> code? >> >> >> Like recent Delphi versions allow by extended RTTI? >> > > FPC will support extended RTTI sooner or later as well. > >> Finally class helpers could solve the problem as well, the cleanest > solution IMO. > > While they would be the cleanest solution they won't work as they can only > go as deep as (strict) protected (which I still not think was a good by > Borland as public/published should have been enough...) > > Regards, > Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
On Sat, 21 Jul 2012, Florian Klämpfl wrote: Am 21.07.2012 23:06, schrieb Ivanko B: No, just reorder the fields so that they can be properly $IFDEFed as protected for nonLAZARUS and left (private) as is otherwise. Why should lazarus people have less chances to mess with private fields? Either we make them public for all or for nobody. Of course, then everybody has to take care of the fact that users might mess with these fields. Which is exactly why we will not do this. The base classes expose a well-defined API. This API is a contract you make with the developers of descendent classes. Some fields are kept private to ensure that the terms of the contract can be met. Making them public/protected means that the terms of the contract can be broken by Developer A, when the code of developer B depends on the terms being rigorously enforced, and his code can go very wrong. This is of course not so for all private fields, which is why I ask for reasons, so I can decide for each field what can or cannot be done. And, if possible, alternative solutions will be presented if they can be found. But for that, I need to know in detail what the problem is in the first place. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
Am 22.07.2012 09:24 schrieb "Hans-Peter Diettrich" : > > Martin schrieb: > >> On 21/07/2012 16:55, Ivanko B wrote: >>> >>> The problem now is that cracker classes can't be used in future anymore >>> because of the new class field ordering optimisation, so I dared to ask. >> >> >>> >>> So, is it possible to design the new feature in such way that to have >>> an option to proceed using cracker classes ? >>> >> >> But the whole discussion comes down to one other simple question. Including the above, the whole discussion is about: >> >>Should FPC provide a way to access private fields from any other code? > > > Like recent Delphi versions allow by extended RTTI? > FPC will support extended RTTI sooner or later as well. > Finally class helpers could solve the problem as well, the cleanest solution IMO. While they would be the cleanest solution they won't work as they can only go as deep as (strict) protected (which I still not think was a good by Borland as public/published should have been enough...) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
Am 22.07.2012 00:23, schrieb Ivanko B: > Why should lazarus people have less chances to mess with private fields? > = > AFAIK, they haven't to use any crackers up to now and it is a normal > way for the mainstream - where complier & IDE are maintained by same > team FPC and Lazarus are not maintained by the same team. FPC and lazarus know only that close cooperation is important and brings benefits for both sides in the long term. > so fixing any bugs is much more urgent than for no-mainstream. What are the numbers of the issues worked around by the crackers? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
Martin schrieb: On 21/07/2012 16:55, Ivanko B wrote: The problem now is that cracker classes can't be used in future anymore because of the new class field ordering optimisation, so I dared to ask. So, is it possible to design the new feature in such way that to have an option to proceed using cracker classes ? But the whole discussion comes down to one other simple question. Including the above, the whole discussion is about: Should FPC provide a way to access private fields from any other code? Like recent Delphi versions allow by extended RTTI? My solution for such problems are local patches to the library source code. A (global) compiler option "treat private as protected" might be another solution. Finally class helpers could solve the problem as well, the cleanest solution IMO. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel