Hi,
On 23 July 2012 15:31, Ian Macintosh 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
someth
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 i
On 22 July 2012 14:22, Hans-Peter Diettrich 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 user
On 22 Jul 2012, at 19:52, Giuliano Colla wrote:
> 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
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
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
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 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
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
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
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
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
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
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
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
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
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
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. :-)
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 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: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
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.
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
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,
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 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 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 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, 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 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
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 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
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 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
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.
> >
> >
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
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
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
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
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
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 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 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
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
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
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
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
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
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
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 fldPri
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 pr
But for very base (not yet specialized) classes - a good idea.
2012/7/22, 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 mai
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
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. O
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
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
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-L
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 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
Or an option:
{$ifdef nonLazarus}
protected
...
{$else}
private
...
{$endif}
Then MSEgui/FPgui/.. may be compiled with "-DnonLazarus" option
2012/7/21, Ivanko B :
> The problem now is that cracker classes can't be used in future anymore
> because of the new class field ordering optimisation, s
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 c
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 fix
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 curr
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 stru
64 matches
Mail list logo
