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 proce
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 no
Am 22.07.2012 09:24 schrieb "Hans-Peter Diettrich" :
>
> Martin schrieb:
>
>> On 21/07/2012 16:55, Ivanko B wrote:
>>>
>>> The problem now is that cracker classes can't be used in future anymore
>>> because of the new class field ordering optimisation, so I dared to
ask.
>>
>>
>>>
>>> So, is
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?
Eithe
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, Marti
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 nu
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* feat
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.
Ther
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 n
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 :
> 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 c
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 re
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.
> >
> >
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
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 an
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 wi
On 22 Jul 2012, at 04:54, silvioprog wrote:
> There MoveChars* function (or similar) native on Free Pascal?
>
> (*) -
> http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/delphivclwin32/System_MoveChars.html
As far as I can tell,
MoveChars(Source,Dest,Lengt
So, there're the following solutions which meet the requirements of
optimization & not breaking non-mainstream code & no need to custom
build FPC:
1) moving related fields from private to protected or even public
(makes the current classes structure more vulnerable)
2) creating protected "brother
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
On Sun, 22 Jul 2012, Jonas Maebe wrote:
On 22 Jul 2012, at 11:50, Martin Schreiber wrote:
Sorry Michael, I do not trust that the effort is worth the outcome for me.
You're really putting us between a rock and a hard place here. It's quite tempting to
retort with "the next time I'll just
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 val
On Sun, 2012-07-22 at 12:40 +0200, Martin Schreiber wrote:
> On Sunday 22 July 2012 12:06:31 Jonas Maebe wrote:
> The situation here is especial because I must convince Michael for things
> that
> is of use for MSEgui only and most likely for no use in Lazarus or
> contradicts his design princi
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 opposit
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,
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 op
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:23:50 Marco van de Voort wrote:
> In our previous episode, Martin Schreiber said:
> > > I don't think it's the best. I'm also quite sure it will require more
> > > work from you in the long run, keeping them up to date and merging bug
> > > fixes and new features from FPC
Am 22.07.2012 13:44, schrieb Martin Schreiber:
On Sunday 22 July 2012 13:23:50 Marco van de Voort wrote:
In our previous episode, Martin Schreiber said:
I don't think it's the best. I'm also quite sure it will require more
work from you in the long run, keeping them up to date and merging bug
f
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
Am 22.07.2012 14:06, schrieb Martin Schreiber:
On Sunday 22 July 2012 13:53:28 Florian Klaempfl wrote:
So classes.pp except for TObject is safe?
Afaik yes. Exception is in sysutils (magic too ?), tobject is in objpas.
Ah, yes. So whole classes unit is independent from compiler. Super. :-)
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 peopl
2012/7/22, Jonas Maebe :
>
> On 22 Jul 2012, at 04:54, silvioprog wrote:
>
>> There MoveChars* function (or similar) native on Free Pascal?
>>
>> (*) -
>> http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/delphivclwin32/System_MoveChars.html
>
> As far as I can te
2012/7/22, silvioprog :
[...]
> to do this at low level.
... in low level ...
--
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 22 Jul 2012, at 20:18, silvioprog wrote:
> 2012/7/22, Jonas Maebe :
>>
>> On 22 Jul 2012, at 04:54, silvioprog wrote:
>>
>>> There MoveChars* function (or similar) native on Free Pascal?
>>>
>>> (*) -
>>> http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/d
2012/7/22, Jonas Maebe :
> On 22 Jul 2012, at 20:18, silvioprog wrote:
>
>> 2012/7/22, Jonas Maebe :
>>>
>>> On 22 Jul 2012, at 04:54, silvioprog wrote:
>>>
There MoveChars* function (or similar) native on Free Pascal?
(*) -
http://docs.embarcadero.com/products/rad_studio/delphi
Then "friend" classes as C++ offers and wait for this feature were
implemented before proceeding with the optimization :)
2012/7/22, Giuliano Colla :
> Il 22/07/2012 10:39, Michael Van Canneyt ha scritto:
>>
>>
>> On Sat, 21 Jul 2012, Florian Klämpfl wrote:
>>
>>> Am 21.07.2012 23:06, schrieb Iva
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
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 w
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
c
Sven Barth schrieb:
>>Should FPC provide a way to access private fields from any other
code?
>
>
> Like recent Delphi versions allow by extended RTTI?
>
FPC will support extended RTTI sooner or later as well.
Hopefully with better means to disable it.
> Finally class helpers could
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" :
>
> 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 i
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
__
Hi,
On 22 July 2012 07:14, Ivanko B wrote:
> private
> prorerty Private1: integer read fldPrivate1 write fldPrivate1;
> prorerty Private2: integer read fldPrivate2 write fldPrivate2;
> protected
> prorerty Private1relaxed: integer read fldPrivate1 write fldPrivate1;
>
> Then MSEgui/FPgui ma
On 22 July 2012 10:09, Martin Schreiber wrote:
> I don't dare to ask for changes so cracker classes were a workaround without
> to bother FPC team.
I sure have had my uphill battles with the FPC team [and not all
turned out as I pleased] - but asking the FPC team for a change must
still be the f
2012/7/22, Hans-Peter Diettrich :
> silvioprog schrieb:
>
>> I could easily do this using "copy", but I'm trying (without success)
>> to do this at low level.
>
> ...where you get what you asked for ;-)
:)
> Why do you want to do things at low level, which can be done easily on
> high level?
>
>
On Monday 23 July 2012 00:17:49 Sven Barth wrote:
> >
> > So classes.pp except for TObject is safe?
>
> TObject is defined in unit System...
>
Yes, Iearned it, thanks. :-)
So classes unit is safe?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepas
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
Am 23.07.2012 06:31 schrieb "Martin Schreiber" :
>
> On Monday 23 July 2012 00:17:49 Sven Barth wrote:
> > >
> > > So classes.pp except for TObject is safe?
> >
> > TObject is defined in unit System...
> >
> Yes, Iearned it, thanks. :-)
I hadn't read the other mails yet that also contained an answ
52 matches
Mail list logo
