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
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
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
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
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
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
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
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
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
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
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 (
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
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
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;
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
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
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
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
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
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
53 matches
Mail list logo
