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
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
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
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
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?
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,
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
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
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.
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.
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
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
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
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
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
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
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
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
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
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
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
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,
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.
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
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.
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.
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?
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
2012/7/22, Jonas Maebe jonas.ma...@elis.ugent.be:
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
2012/7/22, silvioprog silviop...@gmail.com:
[...]
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
2012/7/22, Jonas Maebe jonas.ma...@elis.ugent.be:
On 22 Jul 2012, at 20:18, silvioprog wrote:
2012/7/22, Jonas Maebe jonas.ma...@elis.ugent.be:
On 22 Jul 2012, at 04:54, silvioprog wrote:
There MoveChars* function (or similar) native on Free Pascal?
(*) -
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
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
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
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
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
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
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
___
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
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
40 matches
Mail list logo
