In our previous episode, Andrew Brunner said:
> LOL. I was talking about another way similar to c# namespaces.
Do you have some proposal somewhere? I never understood how this can be
added to FPC (or Delphi) in a workable way.
___
fpc-devel maillist -
Am 10.10.2010 15:41, schrieb Hans-Peter Diettrich:
> Florian Klämpfl schrieb:
>
> What do you feel a need for sorting out?
Splitting the patch in understandable parts which can be committed
separately with appropriate commit messages,
>>> I.e. one patch for every single moved variabl
Florian Klämpfl schrieb:
What do you feel a need for sorting out?
Splitting the patch in understandable parts which can be committed
separately with appropriate commit messages,
I.e. one patch for every single moved variable???
If needed, yes. If one variable is moved and it involves more fi
Am 10.10.2010 06:56, schrieb Hans-Peter Diettrich:
> Florian Klämpfl schrieb:
>> Am 10.10.2010 00:32, schrieb Hans-Peter Diettrich:
>>> Florian Klämpfl schrieb:
>>>
> Now I hope that this patch will be applied to the trunk soon.
No. It's a mess and I won't sort it out.
>>> What do you feel
Florian Klämpfl schrieb:
Am 10.10.2010 00:32, schrieb Hans-Peter Diettrich:
Florian Klämpfl schrieb:
Now I hope that this patch will be applied to the trunk soon.
No. It's a mess and I won't sort it out.
What do you feel a need for sorting out?
Splitting the patch in understandable parts w
Am 10.10.2010 00:32, schrieb Hans-Peter Diettrich:
> Florian Klämpfl schrieb:
>
>>> Now I hope that this patch will be applied to the trunk soon.
>>
>> No. It's a mess and I won't sort it out.
>
> What do you feel a need for sorting out?
Splitting the patch in understandable parts which can be c
Adem schrieb:
On 2010-10-09 16:22, Hans-Peter Diettrich wrote:
The variables have been replaced by (getter) functions, with some
added procedures for updating their values - this is where
getter/setter pairs are inapplicable for structured types, or require
too many consequential changes for
Andrew Brunner schrieb:
2010/10/9 Adem :
Would you consider turning those structured types into objects?
Properties with getter/setter pairs would make tracing (placing a breakpoint
in the getter/sertter would help identify the caller) easier.
The only problem with that line of thinking is th
Florian Klämpfl schrieb:
Now I hope that this patch will be applied to the trunk soon.
No. It's a mess and I won't sort it out.
What do you feel a need for sorting out?
Not to mention the indentation
style not following the style used in the surrounding code,
The new or changed parts can
LOL. I was talking about another way similar to c# namespaces.
On Oct 9, 2010, at 9:59 AM, Michael Van Canneyt wrote:
>
>
> On Sat, 9 Oct 2010, Andrew Brunner wrote:
>
>> 2010/10/9 Adem :
>>> Would you consider turning those structured types into objects?
>>>
>>> Properties with getter/set
On 2010-10-09 17:50, Andrew Brunner wrote:
2010/10/9 Adem:
Would you consider turning those structured types into objects?
Properties with getter/setter pairs would make tracing (placing a breakpoint
in the getter/sertter would help identify the caller) easier.
The only problem with that line
On Sat, 9 Oct 2010, Andrew Brunner wrote:
2010/10/9 Adem :
Would you consider turning those structured types into objects?
Properties with getter/setter pairs would make tracing (placing a breakpoint
in the getter/sertter would help identify the caller) easier.
The only problem with that l
2010/10/9 Adem :
> Would you consider turning those structured types into objects?
>
> Properties with getter/setter pairs would make tracing (placing a breakpoint
> in the getter/sertter would help identify the caller) easier.
The only problem with that line of thinking is that every time your
ar
On 2010-10-09 16:22, Hans-Peter Diettrich wrote:
The variables have been replaced by (getter) functions, with some
added procedures for updating their values - this is where
getter/setter pairs are inapplicable for structured types, or require
too many consequential changes for using pointers
Am 09.10.2010 15:22, schrieb Hans-Peter Diettrich:
> Now I hope that this patch will be applied to the trunk soon.
No. It's a mess and I won't sort it out. Not to mention the indentation
style not following the style used in the surrounding code, comments I
made about the older patch are ignored,
In this new approach I moved some global variables into classes,
omitting variables that require to many consequential changes to the
remaining compiler code - see patch #17584. This patch will allow for
easier implementation of parallel processing in the compiler, or for
multiple front-ends.
16 matches
Mail list logo
