Re: [fpc-devel] Re: Class field reordering
On 22 July 2012 14:22, Hans-Peter Diettrich drdiettri...@aol.com wrote: 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. I agree with this statement as well. -- 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
In our previous episode, Giuliano Colla said: 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. On a per unit basis maybe, but yes. A different class definition would make visible just a few selected classes. It makes quite a difference. Still, anything but syntax. Then directive. (though I still think cmdline is enough) 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. Yes. But this is not about free software principles, since it applies to the binary releases we create, not the source. If it was merely a source issue, maintaining a set of patches would be easy. And I'm still not convinced there really is a /general/ problem, as opposed to a handful of crucial fields, and just trying to cut corners with due process by taking the easiest way out. Sure, there is a lot of sentiment flying around, but that is something different that there really is an acknowledged problem. 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. More likely yet another time sync. Since we are talking issues here that do not appear to be worth filing mantis reports for. 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. Not entirely the same. It would be if the people using these inofficial interfaces only for their own purposes. But this is for projects that pass it on. IOW people will start to base stuff that is based on stuff that is based on volatile interfaces. ___ 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 23 July 2012 15:31, Ian Macintosh ian.macint...@igmac.co.uk wrote: the design concept to me. What Graeme is saying is 100% correct, but also the wrong way to design imho. I don't see it like that. I have developed thousands of classes, and huge frameworks. I often find a new case where I need access to something I haven't thought of before. This is exactly the case here. The FPC team is basing lots of design work on Delphi code, but FPC is also used quite differently to Delphi. So there is no way they could have though of all possible use-cases for each class and every property or field in those classes. Public is simple, it's part of the contract you have in the class. It is what you should rely on not to change, and I always want to make as much as possible public. Visibility rules are a contract. It is easier to add to that contract (make private things protected), that is is to make Public things protected. The latter case will break a lot more code. Saying that, changes must still be justified to make sure that the OOP design stays good and maintainable. -- 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
the users must compile the RTL for non Lazarus use.
=
Really , it needs FPC sources at user's side.
Then a workaround - to maintain protected properties for private variables :
private
fldPrivate1: integer;
fldPrivate2: string;
[..]
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.
Once a cracker disabled, all related fldPrivate(N) needing replacement
with Private(N)relaxed will be revealed at 1-st compilation.
2012/7/22, Martin Schreiber mse00...@gmail.com:
On Saturday 21 July 2012 23:57:50 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.
As I wrote earlier:
Suggestion:
For all FCL base classes which are used in different toolkits and which
can't
be forked without breaking precompiled third party components, namely the
units classes and db, move *all* private fields and methods to protected and
mark them as Use on your own risk, can be changed everytime! Don't cry
afterwards..
The {$ifdef} IvankoB suggests is not ideal because it either needs different
precompiled RTL's or the users must compile the RTL for non Lazarus use.
Martin
___
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
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? shudder 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
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
Am 22.07.2012 09:24 schrieb Hans-Peter Diettrich drdiettri...@aol.com: 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? shudder 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
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 pascaldra...@googlemail.com:
Am 22.07.2012 09:24 schrieb Hans-Peter Diettrich drdiettri...@aol.com:
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? shudder
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 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
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
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 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 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
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
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 jonas.ma...@elis.ugent.be: 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 ivankob4m...@gmail.com: 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 jonas.ma...@elis.ugent.be: 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
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 ivankob4m...@gmail.com: directive to turn said optimization off == But everyone wants the optimization ! (sure without breaking consequences) 2012/7/22, Ivanko B ivankob4m...@gmail.com: 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 jonas.ma...@elis.ugent.be: 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
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
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
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 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
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
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, 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 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 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
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
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 ivankob4m...@gmail.com:
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 pascaldra...@googlemail.com:
Am 22.07.2012 09:24 schrieb Hans-Peter Diettrich
drdiettri...@aol.com:
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? shudder
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 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
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 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
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
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
Sven Barth schrieb: Should FPC provide a way to access private fields from any other code? Like recent Delphi versions allow by extended RTTI? shudder 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
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
Am 22.07.2012 13:18 schrieb Martin Schreiber mse00...@gmail.com: 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
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
Am 23.07.2012 06:31 schrieb Martin Schreiber mse00...@gmail.com: 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
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.
==
The guys, this point is important !
All the discussion members are right in their arguments (Martin's
the community impatience to fixing bugs etc because of intensive
using all range of MSEgui facilities- and the need of the FPC team to
keep the proper class hierachy ) and neither You nor Martin have
enough time to chase tons of code to justify every smallest piece JUST
NOW with hot heads.
So, is it possible to design the new feature in such way that to have
an option to proceed using cracker classes ?
2012/7/19, Jonas Maebe jonas.ma...@elis.ugent.be:
On 19 Jul 2012, at 12:21, _-jan...@web.de wrote:
Unfortunately PACKED is not allowed on all suitable places; there should
be packed set
There's the {$packset xxx} directive you can use.
/array/record/
packed array and packed record both exist.
object/class.
Both respect the current {$packrecords xxx} setting (class only since FPC
2.6.0). If you use {$packrecords 1}, there will be no gaps between the class
fields and hence nothing will ever be reordered either.
Jonas___
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
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? The same dilemma in expressed by: On 14/07/2012 20:46, Jonas Maebe wrote: That may actually lead to quite some troubles: if someone recompiles the RTL without optimizations, then your class crackers also have to change that setting. And there's no way to detect how the RTL (or in general: units containing classes you are cracking) has been compiled in your source code. Adding support for something like that is definitely not a road I want to go down -- even a switch to simply treat all private fields as protected would be less bad (not that I would consider such a switch desirable in any way; it's like adding a switch to allow calling functions only declared in the implementation of another unit). In context of the discussion, if such an optimization can go ahead, or if it would break (valid) code. Jonas says the following (or I read it into it): 1) Support for accessing private fields as if they where protected is not an option 2) Yet he discusses the option of holding back class re-ordering optimization. And 2 is (so far) only for the point of allowing cracker classes (in other words: access to private fields). So in entering the discussion for 2, it seems to me he is in direct contradiction of 1? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
Or an option:
{$ifdef nonLazarus}
protected
...
{$else}
private
...
{$endif}
Then MSEgui/FPgui/.. may be compiled with -DnonLazarus option
2012/7/21, Ivanko B ivankob4m...@gmail.com:
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.
==
The guys, this point is important !
All the discussion members are right in their arguments (Martin's
the community impatience to fixing bugs etc because of intensive
using all range of MSEgui facilities- and the need of the FPC team to
keep the proper class hierachy ) and neither You nor Martin have
enough time to chase tons of code to justify every smallest piece JUST
NOW with hot heads.
So, is it possible to design the new feature in such way that to have
an option to proceed using cracker classes ?
2012/7/19, Jonas Maebe jonas.ma...@elis.ugent.be:
On 19 Jul 2012, at 12:21, _-jan...@web.de wrote:
Unfortunately PACKED is not allowed on all suitable places; there should
be packed set
There's the {$packset xxx} directive you can use.
/array/record/
packed array and packed record both exist.
object/class.
Both respect the current {$packrecords xxx} setting (class only since
FPC
2.6.0). If you use {$packrecords 1}, there will be no gaps between the
class
fields and hence nothing will ever be reordered either.
Jonas___
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
Am 21.07.2012 18:48, schrieb Martin: 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? I don't see cracker classes as valid code. If it works, fine, but it is subject to break. The layout of classes is simply opaque else we open a whole can of worms: like fixed vmt layout or whatever. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
I don't see cracker classes as valid code.
=
Then the FPC team should eliminate the need in such crackers - via
either disabling (via licencing, prisoning etc) the impatient
[mainly because of impatient customers] non-mainstreams (non-Lazarus)
or meeting needs of the non-mainstreams ( the above {$ifdef
nonLazarus} etc ).
2012/7/21, Florian Klämpfl flor...@freepascal.org:
Am 21.07.2012 18:48, schrieb Martin:
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?
I don't see cracker classes as valid code. If it works, fine, but it is
subject to break. The layout of classes is simply opaque else we open a
whole can of worms: like fixed vmt layout or whatever.
___
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
Am 21.07.2012 20:47, schrieb Ivanko B:
I don't see cracker classes as valid code.
=
Then the FPC team should eliminate the need in such crackers - via
either disabling (via licencing, prisoning etc) the impatient
[mainly because of impatient customers] non-mainstreams (non-Lazarus)
or meeting needs of the non-mainstreams ( the above {$ifdef
nonLazarus} etc ).
So you propose we should just remove all privat/protected directives?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
No, just reorder the fields so that they can be properly $IFDEFed as
protected for nonLAZARUS and left (private) as is otherwise. Sure not
every filed but those the non-mainstreams developers ask. This'll
allow the non-mainstreams to start fixing right now.
Florian, it's a huge headache for Martin Graeme to remember explain
all smallest details what when why and they can easily introduce
bugs if fixing their code in a hurry. As they'll remember fix their
code to without cracker they'll be informing the FPC team to delete
related $IFDEF so on.
2012/7/21, Florian Klämpfl flor...@freepascal.org:
Am 21.07.2012 20:47, schrieb Ivanko B:
I don't see cracker classes as valid code.
=
Then the FPC team should eliminate the need in such crackers - via
either disabling (via licencing, prisoning etc) the impatient
[mainly because of impatient customers] non-mainstreams (non-Lazarus)
or meeting needs of the non-mainstreams ( the above {$ifdef
nonLazarus} etc ).
So you propose we should just remove all privat/protected directives?
___
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
Smth like the below:
type
TNonCrackableClass = class
private
fldPrivate1: integer;
fldPrivate2: styring;
{$ifndef nonLazarus}
fldPrivate3: real; // for LAZARUS
{$else}
protected
fldPrivate3: real; // for MSEgui/FPgui
{$endif}
protected
fldProtected1: string
public
[..]
end;
2012/7/22, Ivanko B ivankob4m...@gmail.com:
No, just reorder the fields so that they can be properly $IFDEFed as
protected for nonLAZARUS and left (private) as is otherwise. Sure not
every filed but those the non-mainstreams developers ask. This'll
allow the non-mainstreams to start fixing right now.
Florian, it's a huge headache for Martin Graeme to remember explain
all smallest details what when why and they can easily introduce
bugs if fixing their code in a hurry. As they'll remember fix their
code to without cracker they'll be informing the FPC team to delete
related $IFDEF so on.
2012/7/21, Florian Klämpfl flor...@freepascal.org:
Am 21.07.2012 20:47, schrieb Ivanko B:
I don't see cracker classes as valid code.
=
Then the FPC team should eliminate the need in such crackers - via
either disabling (via licencing, prisoning etc) the impatient
[mainly because of impatient customers] non-mainstreams (non-Lazarus)
or meeting needs of the non-mainstreams ( the above {$ifdef
nonLazarus} etc ).
So you propose we should just remove all privat/protected directives?
___
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
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.
Sure not
every filed but those the non-mainstreams developers ask. This'll
allow the non-mainstreams to start fixing right now.
Florian, it's a huge headache for Martin Graeme to remember explain
all smallest details what when why and they can easily introduce
bugs if fixing their code in a hurry. As they'll remember fix their
code to without cracker they'll be informing the FPC team to delete
related $IFDEF so on.
2012/7/21, Florian Klämpfl flor...@freepascal.org:
Am 21.07.2012 20:47, schrieb Ivanko B:
I don't see cracker classes as valid code.
=
Then the FPC team should eliminate the need in such crackers - via
either disabling (via licencing, prisoning etc) the impatient
[mainly because of impatient customers] non-mainstreams (non-Lazarus)
or meeting needs of the non-mainstreams ( the above {$ifdef
nonLazarus} etc ).
So you propose we should just remove all privat/protected directives?
___
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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
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 so fixing any bugs is much more urgent than for no-mainstream.
Either we make them public for all or for nobody
=
It 'll break the regular (99% of cases) access rights in classes and
may greatly rise number of bugs.
2012/7/22, Florian Klämpfl flor...@freepascal.org:
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.
Sure not
every filed but those the non-mainstreams developers ask. This'll
allow the non-mainstreams to start fixing right now.
Florian, it's a huge headache for Martin Graeme to remember explain
all smallest details what when why and they can easily introduce
bugs if fixing their code in a hurry. As they'll remember fix their
code to without cracker they'll be informing the FPC team to delete
related $IFDEF so on.
2012/7/21, Florian Klämpfl flor...@freepascal.org:
Am 21.07.2012 20:47, schrieb Ivanko B:
I don't see cracker classes as valid code.
=
Then the FPC team should eliminate the need in such crackers - via
either disabling (via licencing, prisoning etc) the impatient
[mainly because of impatient customers] non-mainstreams (non-Lazarus)
or meeting needs of the non-mainstreams ( the above {$ifdef
nonLazarus} etc ).
So you propose we should just remove all privat/protected directives?
___
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
___
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
But for very base (not yet specialized) classes - a good idea.
2012/7/22, Ivanko B ivankob4m...@gmail.com:
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 so fixing any bugs is much more urgent than for no-mainstream.
Either we make them public for all or for nobody
=
It 'll break the regular (99% of cases) access rights in classes and
may greatly rise number of bugs.
2012/7/22, Florian Klämpfl flor...@freepascal.org:
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.
Sure not
every filed but those the non-mainstreams developers ask. This'll
allow the non-mainstreams to start fixing right now.
Florian, it's a huge headache for Martin Graeme to remember explain
all smallest details what when why and they can easily introduce
bugs if fixing their code in a hurry. As they'll remember fix their
code to without cracker they'll be informing the FPC team to delete
related $IFDEF so on.
2012/7/21, Florian Klämpfl flor...@freepascal.org:
Am 21.07.2012 20:47, schrieb Ivanko B:
I don't see cracker classes as valid code.
=
Then the FPC team should eliminate the need in such crackers - via
either disabling (via licencing, prisoning etc) the impatient
[mainly because of impatient customers] non-mainstreams (non-Lazarus)
or meeting needs of the non-mainstreams ( the above {$ifdef
nonLazarus} etc ).
So you propose we should just remove all privat/protected directives?
___
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
___
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
On Saturday 21 July 2012 23:57:50 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.
As I wrote earlier:
Suggestion:
For all FCL base classes which are used in different toolkits and which can't
be forked without breaking precompiled third party components, namely the
units classes and db, move *all* private fields and methods to protected and
mark them as Use on your own risk, can be changed everytime! Don't cry
afterwards..
The {$ifdef} IvankoB suggests is not ideal because it either needs different
precompiled RTL's or the users must compile the RTL for non Lazarus use.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: Class field reordering
In my opinion class field reordering is a great idea I often wished.When I need a definitive layout, I always use PACKED.Unfortunately PACKED is not allowed on all suitable places; there should be packed set/array/record/object/class.Furthermore there should be pseudo-fields/pragmas for packed structures which force an ad-hoc-alignment, e.g.:type t=packed record ... align(4) ... end;The align pragma should force the following field to begin at an address which is divisible by its argument; the argument should be from the set [1,2,4,8,16].There are other places where an align pragma makes sense.The whole discussion centers about dirty hacks to get access to hidden fields which IMHO should be avoided at all cost. The most sensible action is to change all needed fields from private to protected. This is the reason why I almost never use private in my programs - one never knows.Ihr WEB.DE Postfach immer dabei: die kostenlose WEB.DE Mail App fr iPhone und Android.https://produkte.web.de/freemail_mobile_startseite/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
On 19 Jul 2012, at 12:21, _-jan...@web.de wrote:
Unfortunately PACKED is not allowed on all suitable places; there should be
packed set
There's the {$packset xxx} directive you can use.
/array/record/
packed array and packed record both exist.
object/class.
Both respect the current {$packrecords xxx} setting (class only since FPC
2.6.0). If you use {$packrecords 1}, there will be no gaps between the class
fields and hence nothing will ever be reordered either.
Jonas___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
