> On Apr 12, 2019, at 3:52 PM, Jonas Maebe wrote:
>
> Normally, if it can't accept nil it should be var-parameter, and if it can
> then it should be a pointer.
>
> This becomes less clear if a parameter type is already an implicit pointer
> type (like a class or interface), but there are few
On 12/04/2019 21:11, Ryan Joseph wrote:
What do you do about the problem of not knowing when a parameter of a 3rd party
function can accept null?
Normally, if it can't accept nil it should be var-parameter, and if it
can then it should be a pointer.
This becomes less clear if a parameter ty
> On Apr 12, 2019, at 2:55 PM, Marco van de Voort
> wrote:
>
> I think the same as when I read the suggestion for an inout variant of VAR.
> Move this out of the language syntax, and make it directives or attribute
> like syntax (like we will need to get anyway for const ref).
Example pleas
Ryan Joseph schrieb am Fr., 12. Apr. 2019,
16:37:
>
>
> > On Apr 12, 2019, at 10:15 AM, Michael Van Canneyt <
> mich...@freepascal.org> wrote:
> >
> > That would break with the rule that directives do not cross unit
> boundaries.
> > It has far-reaching consequences.
> >
> > Better introduce a co
Op 2019-04-12 om 17:23 schreef Ryan Joseph:
What do you think of that? Sounds like an easy way to get some support for nil pointers deref’s and provides self documenting code.
I think the same as when I read the suggestion for an inout variant of
VAR. Move this out of the language syntax, a
I had another idea yesterday while working with Swift and I was curious to hear
what anyone thought. In Pascal we have “const”, “constref" “var”, “out” params
for functions but no way to document or enforce optional params (which are
pointers/classes).
It’s a very common pattern that a function
On Fri, 12 Apr 2019, Joao Schuler wrote:
I would use something like {$include mysettings.inc} .
Exactly.
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
On Fri, 12 Apr 2019, Ryan Joseph wrote:
On Apr 12, 2019, at 10:15 AM, Michael Van Canneyt
wrote:
That would break with the rule that directives do not cross unit boundaries.
It has far-reaching consequences.
Better introduce a command-line switch to set mode switches.
But is it maybe
> On Apr 12, 2019, at 10:15 AM, Michael Van Canneyt
> wrote:
>
> That would break with the rule that directives do not cross unit boundaries.
> It has far-reaching consequences.
>
> Better introduce a command-line switch to set mode switches.
But is it maybe time we reconsider this or add an
I would use something like {$include mysettings.inc} .
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
On Fri, 12 Apr 2019, Ryan Joseph wrote:
Can I propose we add a new $modeswitch-all (or some equivalent) that globally
sets modeswitch in all subsequent units? I’m thinking about how messy this list
is getting after these new mode switches are added and that the problem is only
going to grow
Can I propose we add a new $modeswitch-all (or some equivalent) that globally
sets modeswitch in all subsequent units? I’m thinking about how messy this list
is getting after these new mode switches are added and that the problem is only
going to grow. I really like how FPC lets us opt into spec
Graeme Geldenhuys schrieb am Fr., 12. Apr.
2019, 14:20:
> On 12/04/2019 13:10, Graeme Geldenhuys wrote:
> > On 12/04/2019 12:40, Mattias Gaertner via fpc-pascal wrote:
> >> I get:
> >> test1.pas(26,8) Error: identifier idents no member "FDropDown"
> >
> > It works in Delphi 10.2.3
>
>
> Ah wait,
On 12/04/2019 13:10, Graeme Geldenhuys wrote:
> On 12/04/2019 12:40, Mattias Gaertner via fpc-pascal wrote:
>> I get:
>> test1.pas(26,8) Error: identifier idents no member "FDropDown"
>
> It works in Delphi 10.2.3
Ah wait, the code comment was wrong. Those fields were actually "strict
protected",
On 12/04/2019 12:40, Mattias Gaertner via fpc-pascal wrote:
> I get:
> test1.pas(26,8) Error: identifier idents no member "FDropDown"
It works in Delphi 10.2.3
> Helpers are broken in several ways, but it seems this is not one of
> them.
Seems FPC is better than Delphi then. Or its a FPC bu
I'm not sure if this is anything you're interested in but ...
You can qualify the of the procedure with the unit or program identifier.
program Test;
{$mode objfpc}
type
THelper = class helper for TObject
procedure DoThis;
end;
procedure DoThis(Param: string);
begin
WriteLn(Param);
e
On Fri, 12 Apr 2019 12:23:15 +0100
Graeme Geldenhuys wrote:
> Hi,
>
> What exactly is the point of "strict private"? I believe FPC supports
> it too, after Delphi added it. It makes absolutely no senses to me.
> From the name and original intent, it means it is "really really
> private" even in
Hi,
What exactly is the point of "strict private"? I believe FPC supports it
too, after Delphi added it. It makes absolutely no senses to me. From
the name and original intent, it means it is "really really private"
even in the same unit.
Yet you do something like this... and you have access to t
18 matches
Mail list logo
