Re: [fpc-pascal] non-virtual class methods called from virtual regular method
On 29/04/2021 13:04, LacaK via fpc-pascal wrote: > In regular virtual method, I expect, that Self resolves to runtime class > type, thust calling CP1 should resolve to runtime type class method. It works the same for class methods and non-class methods: no virtual = no dynamic resolution when calling such a method. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Detecting IO errors with INI file
Thanks everyone for the help. I have it working now
I did some more searching and found out I can get "Try" to work with {$Mode TP}
If I add {$Modeswitch exceptions} and appearantly {$R+} to make sure range
checking is on.
So I have it working in my {$Mode TP} Unit.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Array range overflow in properties
Is this a bug in properties and I should be getting an error? type TPixel = record components: array[0..3] of byte; property R: byte read components[10] write components[10]; end; Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [fpc-devel] Nested function closures
> On Apr 29, 2021, at 12:01 AM, Sven Barth wrote:
>
> To be precise there are two more: function/procedure variables (no special
> designator) and method variables ("of object"). Depending on what a anonymous
> function captures (or for the sake of it a nested function) it would be
> possible to assign it to such a type as well (for a function variable only
> global variables may be used, for a method variable additionally Self may be
> used).
As I remember the capturing code for nested functions and the new closures are
not shared. That means when the parser encounters an anonymous function it
needs to decide which type of capture it will use, right? In that case the user
may need to state that the anon function is "nested" otherwise it will use the
wrong capturing method.
>
> So once the current work is done we have 2 kinds of closures but only one of
> those is compatible with anonymous functions and this is why I want the other
> closures (nested functions) to have the same pair of functionality.
>
> Once anonymous functions are supported we can improve their compatibility
> with other constructs.
>
Great, that's what I wanted to do. It's well worth the time to get anon
functions for callbacks that return immediately, list.ForEach, list.Sort etc
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Detecting IO errors with INI file
On Thu, 29 Apr 2021, James Richters via fpc-pascal wrote: Best add SysUtils and Classes. Thanks, that worked. But now I'm getting "cannot read or write variables of this type" for Writeln(Exception) is there an easy way to find out what the exception is? On E : Exception do Writeln(E.ClassName,' : ',E.Message); Adapt E to whatever variable you used. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Detecting IO errors with INI file
>Best add SysUtils and Classes. Thanks, that worked. But now I'm getting "cannot read or write variables of this type" for Writeln(Exception) is there an easy way to find out what the exception is? James ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] non-virtual class methods called from virtual regular method
On Thu, 29 Apr 2021, LacaK via fpc-pascal wrote: Dňa 29.4.2021 o 9:26 Michael Van Canneyt via fpc-pascal napísal(a): On Thu, 29 Apr 2021, LacaK via fpc-pascal wrote: Hi *, consider the following example T1 = class class procedure CP1; procedure P1; virtual; end; T2 = class(T1) class procedure CP1; end; procedure T1.P1; begin CP1; // here is called allways T1.CP1, right? // if I want call T2.CP1 then class procedure CP1 must be also virtual, right? Yes // so Self.CP1 does not take runtime type but is staticaly resolved at compile time to T1.CP1 ? Yes. This is bit counter-intuitive for me: For me not, it's perfectly logical. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Detecting IO errors with INI file
On Thu, 29 Apr 2021, James Richters via fpc-pascal wrote:
I’m trying to put the Ini file stuff all in it’s own unit.
My unit is {$Mode OBJFPC}
and Uses IniFiles;
“Try” is compiling, but I’m getting Error: Identifier not found “EFOpenError”
And also Syntax error “Do” expected but “)” found
I have:
try
Log_ini := TIniFile.Create('myini.ini');
except
on e: EFOpenError do // Identifier not found “EFOPenError”
Writeln(EFOpenError);
on e: Exception do
Writeln(Exception);
end;
Do I need some other unit for EFOpenError to work?
Best add SysUtils and Classes.
Michael.___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] non-virtual class methods called from virtual regular method
Dňa 29.4.2021 o 9:26 Michael Van Canneyt via fpc-pascal napísal(a): On Thu, 29 Apr 2021, LacaK via fpc-pascal wrote: Hi *, consider the following example T1 = class class procedure CP1; procedure P1; virtual; end; T2 = class(T1) class procedure CP1; end; procedure T1.P1; begin CP1; // here is called allways T1.CP1, right? // if I want call T2.CP1 then class procedure CP1 must be also virtual, right? Yes // so Self.CP1 does not take runtime type but is staticaly resolved at compile time to T1.CP1 ? Yes. This is bit counter-intuitive for me: In regular virtual method, I expect, that Self resolves to runtime class type, thust calling CP1 should resolve to runtime type class method. But from compiler POV I understand, that symbol CP1 must be somehow resolved at compile time, so compiler looks at CP1 method definition (and if not virtual then resolves to class method of type where is used). In principle *virtual* class methods as such are for me strange ;-) end; var c1: T1; begin c1:=T2.Create; c1.P1; // here is called T2.P1 - runtime class type end. Thanks Btw If I need for various class descendants define various class constants, it is possible only by using class functions (getters), where descendant class getter hides parents getter? If they depend on the class, they're not "constants" to begin with, so a getter function is the right approach. For such purposes I use virtual class functions. Yes, on other side virtual constants will be construct which I would understand better: If I need override some class wide parameter: T1 = class private const CPORT=0; // virtual end; T1 = class (T2) private const CPORT=2; // override end; Now I must do: T1 = class private class procedure GetPORT: integer; virtual; end; T2 = class(T1) private class procedure GetPORT: integer; override; end; class procedure T1.GetPORT: integer; begin Result := 0; end; class procedure T2.GetPORT: integer; begin Result := 2; end; I accept, that polymorphism in class inheritance work this way ... L. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Detecting IO errors with INI file
I’m trying to put the Ini file stuff all in it’s own unit.
My unit is {$Mode OBJFPC}
and Uses IniFiles;
“Try” is compiling, but I’m getting Error: Identifier not found “EFOpenError”
And also Syntax error “Do” expected but “)” found
I have:
try
Log_ini := TIniFile.Create('myini.ini');
except
on e: EFOpenError do // Identifier not found “EFOPenError”
Writeln(EFOpenError);
on e: Exception do
Writeln(Exception);
end;
Do I need some other unit for EFOpenError to work?
James
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Detecting IO errors with INI file
James Richters schrieb am Do.,
29. Apr. 2021, 10:33:
> I get Error: Identifier not found “Try”
>
> Because my unit must be compiled with {$MODE TP}
>
You can try to use {$modeswitch exceptions}, I think.
Otherwise quite a few procedures and functions won’t even compile that only
> work in Turbo Pascal mode.
>
>
>
> I guess I can put it in another unit and make a call to that… then I can
> use Try
>
Considering that you're using Object Pascal functionality with TIniFile it
might be best to put that into a separate unit.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [fpc-devel] Nested function closures
On 2021-04-29 09:00, Mattias Gaertner via fpc-pascal wrote: On Thu, 29 Apr 2021 07:52:19 +0200 Sven Barth via fpc-pascal wrote: [...] You completely ignored my first point, which in this case is the much more significant one: Pascal does not support type inference. FPC does not. Delphi does: http://docwiki.embarcadero.com/RADStudio/Sydney/en/Inline_Variable_Declaration begin var MyDictionary := TDictionary.Create; for var I:=1 to 10 do ; end. Are you aware that Delphi limits this specifically to inline variable declaration (quoting including the typo: "compiler can now in several circumstances infer the type of a variable at ints line declaration location")? One could argue to which extent are inline variable declarations still Pascal... :/ (I have my opinion about this, but let's save everybody from a flamewar about this topic.) Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Detecting IO errors with INI file
I get Error: Identifier not found “Try”
Because my unit must be compiled with {$MODE TP}
Otherwise quite a few procedures and functions won’t even compile that only
work in Turbo Pascal mode.
I guess I can put it in another unit and make a call to that… then I can use Try
Thanks for the information.
James
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [fpc-devel] Nested function closures
On 29/04/2021 8:00 am, Mattias Gaertner via fpc-pascal wrote: > FPC does not. > Delphi does: If only FPC would have strived to be Delphi Compatible. ;-) :-P Regards, Graeme ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] non-virtual class methods called from virtual regular method
On Thu, 29 Apr 2021, LacaK via fpc-pascal wrote: Hi *, consider the following example T1 = class class procedure CP1; procedure P1; virtual; end; T2 = class(T1) class procedure CP1; end; procedure T1.P1; begin CP1; // here is called allways T1.CP1, right? // if I want call T2.CP1 then class procedure CP1 must be also virtual, right? Yes // so Self.CP1 does not take runtime type but is staticaly resolved at compile time to T1.CP1 ? Yes. end; var c1: T1; begin c1:=T2.Create; c1.P1; // here is called T2.P1 - runtime class type end. Thanks Btw If I need for various class descendants define various class constants, it is possible only by using class functions (getters), where descendant class getter hides parents getter? If they depend on the class, they're not "constants" to begin with, so a getter function is the right approach. For such purposes I use virtual class functions. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [fpc-devel] Nested function closures
On Thu, 29 Apr 2021 07:52:19 +0200 Sven Barth via fpc-pascal wrote: >[...] > You completely ignored my first point, which in this case is the much > more significant one: Pascal does not support type inference. FPC does not. Delphi does: http://docwiki.embarcadero.com/RADStudio/Sydney/en/Inline_Variable_Declaration begin var MyDictionary := TDictionary.Create; for var I:=1 to 10 do ; end. > It is impossible to implement a syntax like you're suggesting without > major rework of the parser. Indeed. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] non-virtual class methods called from virtual regular method
Hi *, consider the following example T1 = class class procedure CP1; procedure P1; virtual; end; T2 = class(T1) class procedure CP1; end; procedure T1.P1; begin CP1; // here is called allways T1.CP1, right? // if I want call T2.CP1 then class procedure CP1 must be also virtual, right? // so Self.CP1 does not take runtime type but is staticaly resolved at compile time to T1.CP1 ? end; var c1: T1; begin c1:=T2.Create; c1.P1; // here is called T2.P1 - runtime class type end. Thanks Btw If I need for various class descendants define various class constants, it is possible only by using class functions (getters), where descendant class getter hides parents getter? -Laco. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [fpc-devel] Nested function closures
Ryan Joseph via fpc-pascal schrieb am
Mi., 28. Apr. 2021, 17:53:
>
>
> > On Apr 27, 2021, at 11:36 PM, Sven Barth
> wrote:
> >
> > Anyway, it would in principle be possible to convert an anonymous
> function to a "is nested" function, but that will only come *after* the
> whole implementation is here so that the chance for messing that core
> functionality (!) up is reduced.
>
> Sorry I'm struggling with all these new terms myself. Yes that is what I'm
> proposing and what I demonstrated in that GitHub branch. We talked about
> this in 2018 but you said to wait until the "real thing" was finished so I
> let it be. I brought this up again now to say that when, and not before,
> the closures are finished and in trunk I will see how to integrate the
> "nested anonymous functions" into the new system.
>
> To clarify for myself, we have a few concepts here:
>
> - Closures: blocks which capture variables in scope and wrap them into a
> container (nested functions use a record I think and closures will use an
> interface).
>
Nested functions simply use the framepointer. They are using it like a
record, but in essence it's simply the framepointer...
- Anonymous procedures: Simply an anonymous procedure/function body which
> lacks a name and can be declared inside code blocks.
>
Correct.
- 2 Procedure types: "reference to" and "is nested". On the caller side
> these are what control which kind of closure is used is used. Is that
> correct? So the anonymous function doesn't really become a closure until
> it's passed to a "reference to" or "is nested" variable.
>
To be precise there are two more: function/procedure variables (no special
designator) and method variables ("of object"). Depending on what a
anonymous function captures (or for the sake of it a nested function) it
would be possible to assign it to such a type as well (for a function
variable only global variables may be used, for a method variable
additionally Self may be used).
So once the current work is done we have 2 kinds of closures but only one
> of those is compatible with anonymous functions and this is why I want the
> other closures (nested functions) to have the same pair of functionality.
>
Once anonymous functions are supported we can improve their compatibility
with other constructs.
Regards,
Sven
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
