Re: [fpc-pascal] GetLocaleInfo returns ZZZ

[Michael Van Canneyt]

On Thu, 22 Feb 2018, Darius Blaszyk wrote:


On my machine getlocaleinfo returns ZZZ when requesting the abbrev langname. 
The country code is correctly set to NL. This makes gettext.GetLanguageIDs 
return zz_NL. What could be causing this?

Also the behavior of GetLocaleInfoIDs does not seem to be according to the 
gettext manual. On windows the locale is determined by the Win API and on all 
other platforms the environment variables are checked as they are described in 
the manual but the first LANGUAGE env var is not probed and followed. This env 
var gives the preferred order of translations.

I would like to align this functionality over the platforms, but want to
ask for advice wether or not a patch would be accepted.


If you make a test program that shows the bug, and correct it, a patch will
be accepted.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Scoped enums and inferred types

[russeld]

Pascal allows type declarations at the procedure level, so you could use type
aliases to reduce your typing and still have code completion:

procedure foo();
type 
  SVK = NSSomeLongNameOfSomethingValueKey;
var
  a: SVK;
begin
  a := SVK.some_key_value;
end;

If you tried to use SVK elsewhere an error would be raised

Regards
Russ

   



--
Sent from: http://free-pascal-general.1045716.n5.nabble.com/
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpreport rangeerrors with TFPReportColor

[Michael Van Canneyt]

On Thu, 22 Feb 2018, Andreas Frieß wrote:


Another possible Problem with the definition

TFPColor (fpc)  record with word <> TColor (lazarus) 
-$7FFF-1..$7FFF <> TFPReportColor (fpreport) UInt32


So you cannot use in Lazarus the 'well known' TColors. With TColor it is 
also Delphi compatible.


Using TColor is not an option, it is windows specific and depeds on Graphics.

Michael.___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] GetLocaleInfo returns ZZZ

[Darius Blaszyk]

On my machine getlocaleinfo returns ZZZ when requesting the abbrev langname. 
The country code is correctly set to NL. This makes gettext.GetLanguageIDs 
return zz_NL. What could be causing this?

Also the behavior of GetLocaleInfoIDs does not seem to be according to the 
gettext manual. On windows the locale is determined by the Win API and on all 
other platforms the environment variables are checked as they are described in 
the manual but the first LANGUAGE env var is not probed and followed. This env 
var gives the preferred order of translations.

I would like to align this functionality over the platforms, but want to ask 
for advice wether or not a patch would be accepted.

Rgds Darius

Verstuurd vanaf mijn iPhone
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpreport rangeerrors with TFPReportColor

[Andreas Frieß]

Another possible Problem with the definition

TFPColor (fpc)  record with word <> TColor (lazarus) 
-$7FFF-1..$7FFF <> TFPReportColor (fpreport) UInt32


So you cannot use in Lazarus the 'well known' TColors. With TColor it is 
also Delphi compatible.


If the defines are Lazarus compatible. It works for both systems. I can 
make a patch if needed. But the teams have to IMHO to decide the best 
way :-)


Andreas


Am 21.02.2018 um 23:53 schrieb Michael Van Canneyt:



On Wed, 21 Feb 2018, Mattias Gaertner wrote:


On Wed, 21 Feb 2018 19:54:55 +
Graeme Geldenhuys  wrote:


[...]
> Because UInt32 is not a JSON dataformat.
Well, then I'll say that FPC's JSON needs to be extended to support 
UInt32, as it is a perfectly valid Object Pascal data type.


How should FPC's JSON support something, that is not supported by
JSON?


The problem is not in JSON.

Native Javascript supports 2^52 (or so) integer values, so every 
UInt32 value should fit

if written properly.

FPC's JSON supports Int64 and even QWord in FPC, so a UInt32 is 
definitely supported.


If the colors (a UInt32) is currently written as Longint (signed 
32-bit) then of course a range check will follow, and this needs to be 
fixed.


The easiest solution is simply to read/write it as Int64.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpreport rangeerrors with TFPReportColor

[Michael Van Canneyt]

On Wed, 21 Feb 2018, Mattias Gaertner wrote:


On Wed, 21 Feb 2018 19:54:55 +
Graeme Geldenhuys  wrote:


[...]
> Because UInt32 is not a JSON dataformat. 

Well, then I'll say that FPC's JSON needs to be extended to support 
UInt32, as it is a perfectly valid Object Pascal data type.


How should FPC's JSON support something, that is not supported by
JSON?


The problem is not in JSON.

Native Javascript supports 2^52 (or so) integer values, so every UInt32 value 
should fit
if written properly.

FPC's JSON supports Int64 and even QWord in FPC, so a UInt32 is definitely 
supported.

If the colors (a UInt32) is currently written as Longint (signed 32-bit) 
then of course a range check will follow, and this needs to be fixed.


The easiest solution is simply to read/write it as Int64.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Scoped enums and inferred types

[Benito van der Zander]

Hi Fpc-pascal Users,

I simply rely on my IDE (Lazarus, Visual Studio)  to complete long 
identifier names for me so that I don't have to. *shrugs*



 but you still need to read the identifiers and when they are too long, 
that takes time, too




How does that look?


No idea how it looked, but it could look like this:

uses definingUnit.TTileSortingFlag;

-> you need to write TTileSortingFlag.Static

uses definingUnit.TTileSortingFlag.Static;

or

uses definingUnit.TTileSortingFlag.*;

-> you can just write Static


Alternatively:

with TTileSortingFlag do

to just write Static
Bye,
Benito


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpreport rangeerrors with TFPReportColor

[Mattias Gaertner]

On Wed, 21 Feb 2018 19:54:55 +
Graeme Geldenhuys  wrote:

>[...]
> > Because UInt32 is not a JSON dataformat.  
> 
> Well, then I'll say that FPC's JSON needs to be extended to support 
> UInt32, as it is a perfectly valid Object Pascal data type.

How should FPC's JSON support something, that is not supported by
JSON?

Mattias
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Scoped enums and inferred types

[Marco van de Voort]

In our previous episode, Ryan Joseph said:
> > Having to decide a variable is scoped or not when it is declared is not the
> > most ideal solution anyway.  Logically you would decide that when creating
> > the scope, iow when importing, like in Modula2 or (afaik also) Extended
> > Pascal.
> 
> How does that look?

I don't know the EP syntax by heart, but M2 had

IMPORT X; 

and

FROM X IMPORT Y;
FROM X IMPORT QUALIFIED Y;

The first would import all identifiers of a module qualified (iow scoped),
so you could only access them as X.Y

The second one imports Y for use unqualified (so just "Y"), and the third,
as the keyword says, qualified again, but for a single identifier. The
places where Y is used in the FROM..IMPORt can be lists.

There was no unqualified mass-IMPORT (which would be like our USES).

IIRC FROM..IMPORTing an enum also imported all its fields, but I'm not
entirely sure, it has been 15+ years :-)

The system gave a lot of control, but as with all control that comes with a
lot of micromanaging and administration. While the purist probably won't
agree I missed an unqualified import (simples USES) dearly.

Still, it would be nice to have some similar control for special cases.

E.g. I can imagine very well that it would be nice to only import a handful of
procs and types from unit windows and avoid polution, and scoping all enums,
but descoping them with from import for special or heavy-usage cases.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpreport rangeerrors with TFPReportColor

[Graeme Geldenhuys]

On 2018-02-21 08:48, Andreas Frieß wrote:


The definition is TFPReportColor  = type UInt32;


That was designed and defined to handle AARRGGBB values of $ 
(max 256 for each color channel and alpha), and that fits perfectly in a 
UInt32 data type.



Should the definition for TFPReportColor not better TFPColor


I can't remember from memory. Is TFPColor the one where each color 
channel is a Word size (ie: $)?  When I wrote fpReport, that color 
range was note designed for and I've never seen in used in the 
real-world either.




Because UInt32 is not a JSON dataformat.


Well, then I'll say that FPC's JSON needs to be extended to support 
UInt32, as it is a perfectly valid Object Pascal data type.



Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Scoped enums and inferred types

[Bernd Oppolzer]

Am 21.02.2018 um 16:29 schrieb Ryan Joseph:



On Feb 21, 2018, at 10:13 PM, Michael Van Canneyt  
wrote:

You lose an important type safety if you replace them with constants.

I like enums also but you can imagine when they were proposed the compiler 
teams probably compared them to constants and decided if they were worth it 
bloat or not (much like my suggestion and what Swift decided to do). Ultimately 
it’s just another thing the user can do themselves instead of compiler but if 
you follow that road too far you’re back to assembly (on the other end is 
Java/Swift super high level languages).

Btw did enums exist in the first Pascal specs? I honestly kind of forgot about 
them since I was doing desktop apps from C based API’s that used all constants.


the very first Pascal specifications of the 1970s had enums,
but they were called "scalar types" at that time.

see page 10: http://bernd-oppolzer.de/PascalReport.pdf
(page 18 of the PDF).

Kind regards

Bernd




Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] GetLocaleInfo returns ZZZ

[Bart]

On Wed, Feb 21, 2018 at 12:11 PM, Darius Blaszyk  wrote:
> On my machine getlocaleinfo returns ZZZ when requesting the abbrev langname. 
> The country code is correctly set to NL. This makes gettext.GetLanguageIDs 
> return zz_NL. What could be causing this?


Maybe the same as:
http://www.hu.freepascal.org/lists/fpc-devel/2011-January/023648.html

Bart
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Scoped enums and inferred types

[Ryan Joseph]

> On Feb 21, 2018, at 10:13 PM, Michael Van Canneyt  
> wrote:
> 
> You lose an important type safety if you replace them with constants.

I like enums also but you can imagine when they were proposed the compiler 
teams probably compared them to constants and decided if they were worth it 
bloat or not (much like my suggestion and what Swift decided to do). Ultimately 
it’s just another thing the user can do themselves instead of compiler but if 
you follow that road too far you’re back to assembly (on the other end is 
Java/Swift super high level languages).

Btw did enums exist in the first Pascal specs? I honestly kind of forgot about 
them since I was doing desktop apps from C based API’s that used all constants.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Scoped enums and inferred types

[Ryan Joseph]

> On Feb 21, 2018, at 10:18 PM, Marco van de Voort  wrote:
> 
> Having to decide a variable is scoped or not when it is declared is not the
> most ideal solution anyway.  Logically you would decide that when creating
> the scope, iow when importing, like in Modula2 or (afaik also) Extended
> Pascal.

How does that look?

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Scoped enums and inferred types

[Marco van de Voort]

In our previous episode, Ryan Joseph said:

> Adding compiler features is a slippery slope and I have no idea where to
> draw lines.  Scoped enums aren?t necessary and in fact enums in general
> could be replaced with constants easily enough so that feature was
> probably debated at some point also.

Having to decide a variable is scoped or not when it is declared is not the
most ideal solution anyway.  Logically you would decide that when creating
the scope, iow when importing, like in Modula2 or (afaik also) Extended
Pascal.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Scoped enums and inferred types

[Michael Van Canneyt]

On Wed, 21 Feb 2018, Ryan Joseph wrote:





On Feb 21, 2018, at 5:16 PM, Sven Barth via fpc-pascal 
 wrote:

I simply rely on my IDE (Lazarus, Visual Studio)  to complete long identifier 
names for me so that I don't have to. *shrugs*


Sure enough it’s not a pressing matter by any means but I thought it was worth asking about since I saw it in Swift and it made sense. 


Adding compiler features is a slippery slope and I have no idea where to
draw lines.  Scoped enums aren’t necessary and in fact enums in general
could be replaced with constants easily enough so that feature was
probably debated at some point also.


You lose an important type safety if you replace them with constants.

Enums have their uses.

As long as you stick to conservative use and accept that the compiler
manages them, they are a powerful and useful construct. Otherwise you're
probably better off using constants.

Michael.___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Scoped enums and inferred types

[Ryan Joseph]

> On Feb 21, 2018, at 5:16 PM, Sven Barth via fpc-pascal 
>  wrote:
> 
> I simply rely on my IDE (Lazarus, Visual Studio)  to complete long identifier 
> names for me so that I don't have to. *shrugs*

Sure enough it’s not a pressing matter by any means but I thought it was worth 
asking about since I saw it in Swift and it made sense. 

Adding compiler features is a slippery slope and I have no idea where to draw 
lines. Scoped enums aren’t necessary and in fact enums in general could be 
replaced with constants easily enough so that feature was probably debated at 
some point also.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Scoped enums and inferred types

[Martok]

Am 21.02.2018 um 10:45 schrieb Michael Van Canneyt:
> I was waiting for this reply from you. You didn't disappoint ;)
Got an image to maintain ;-)

Took me long enough to come up with that actually fairly simple workaround,
might as well save others the trouble.

That stuff is like "bad keming", I just can't un-see it.
In related news: the example program for #32743 is undefined with more than 10
arguments in fpc and does, in fact, generate slightly wonky code that falls
apart at 255 arguments.


Regards,
Martok

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpreport rangeerrors with TFPReportColor

[Andreas Frieß]

Andreas Frieß wrote:

> when i compile in Lazarus the Reportdesigner with activated
> RangeCheck it gives a lot of runtimeerror with rangeerrors.
>


For explanation what i mean in my previous post, UInt32 is not an
integer or JSON compatible size (and actual rangecheck unsafe).

ANdreas

--


in systemh.inc

  maxLongint  = $7fff;

in objectpas.pp
    const
   MaxInt  = MaxLongint;
    type
   Integer  = longint;

in fpreport.pp

  TFPReportColor  = type UInt32;

in systemh.inc

  Cardinal = LongWord;
...
  UInt32  = Cardinal;

in fpreport.pp

const
  { The format is always RRGGBB (Red, Green, Blue) - no alpha channel }
  clNone  = TFPReportColor($8000);  // a special condition:
$80 00 00 00

..
    AWriter.WriteInteger('FontColor', Font.Color);
.
    Font.Color := AReader.ReadInteger('FontColor', Font.Color);
..

in fpReportStreamer.pp

function TFPReportJSONStreamer.ReadInteger(AName: String; ADefault:
Integer): Integer;
var
  d: TJSONData;
begin
  d := FindChild(AName) as TJSONData;
  if d = nil then
    Result := ADefault
  else
  begin
    if d.JSONType = jtNumber then
  Result := d.AsInt64
    else
  Result := ADefault;
  end;
end;



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Scoped enums and inferred types

[wkitty42]

On 02/21/2018 05:16 AM, Sven Barth via fpc-pascal wrote:

I simply rely on my IDE (Lazarus, Visual Studio)  to complete long identifier
 names for me so that I don't have to. *shrugs*


exactly my thoughts, too...


--
 NOTE: No off-list assistance is given without prior approval.
   *Please keep mailing list traffic on the list unless*
   *a signed and pre-paid contract is in effect with us.*
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] GetLocaleInfo returns ZZZ

[Darius Blaszyk]

On my machine getlocaleinfo returns ZZZ when requesting the abbrev langname. 
The country code is correctly set to NL. This makes gettext.GetLanguageIDs 
return zz_NL. What could be causing this?

Also the behavior of GetLocaleInfoIDs does not seem to be according to the 
gettext manual. On windows the locale is determined by the Win API and on all 
other platforms the environment variables are checked as they are described in 
the manual but the first LANGUAGE env var is not probed and followed. This env 
var gives the preferred order of translations.

I would like to align this functionality over the platforms, but want to ask 
for advice wether or not a patch would be accepted.

Rgds Darius

Verstuurd vanaf mijn iPhone
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Scoped enums and inferred types

[Michael Van Canneyt]

On Wed, 21 Feb 2018, Sven Barth via fpc-pascal wrote:


Am 21.02.2018 09:48 schrieb "Ryan Joseph" :




On Feb 21, 2018, at 2:57 PM, Michael Van Canneyt 

wrote:


The job of the compiler is to create correct code. Not to ensure you

write readable code. Every feature that is introduced

offers more scope for abuse (generics jump to mind).


I think you may change your mind if you had to type
NSSomeLongNameOfSomethingValueKey all day instead of .Value. Remembering
prefix names is a waste of my time if the compiler can do it for me. 
I wonder how many hours total in my life I’ve spent writing lists of

constants with prefixes and then typing them back out in function calls.


I simply rely on my IDE (Lazarus, Visual Studio)  to complete long
identifier names for me so that I don't have to. *shrugs*


My point exactly. Not the job of the compiler.

Michael.___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Scoped enums and inferred types

[Sven Barth via fpc-pascal]

Am 21.02.2018 09:48 schrieb "Ryan Joseph" :



> On Feb 21, 2018, at 2:57 PM, Michael Van Canneyt 
wrote:
>
> The job of the compiler is to create correct code. Not to ensure you
write readable code. Every feature that is introduced
> offers more scope for abuse (generics jump to mind).

I think you may change your mind if you had to type
NSSomeLongNameOfSomethingValueKey all day instead of .Value. Remembering
prefix names is a waste of my time if the compiler can do it for me. I
wonder how many hours total in my life I’ve spent writing lists of
constants with prefixes and then typing them back out in function calls.


I simply rely on my IDE (Lazarus, Visual Studio)  to complete long
identifier names for me so that I don't have to. *shrugs*

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Scoped enums and inferred types

[Michael Van Canneyt]

On Wed, 21 Feb 2018, Martok wrote:


I doubt that many would be using scopedenums for that.

Isn't that what they're for?

{$SCOPEDENUMS ON}
type
 TTileSortingFlag = (Static,
 Ramp,
 Ignore,
 Particle,
 Floor,
 Flat,
 Container,
 OnRamp,
 BufferStatic,
 BufferDynamic
 );

As a side note, Ryan: if you need to interoperate with other languages, using
enums is dangerous. FPC has different enum storage semantics from most other
compilers, and will happily drop you into "undefined" behaviour.


I was waiting for this reply from you. You didn't disappoint ;)

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Scoped enums and inferred types

[Mattias Gaertner]

On Wed, 21 Feb 2018 16:14:13 +0700
Ryan Joseph  wrote:

>[...]
> {$scopedenums on}
> type
>   TTileSortingFlag = (Static, 
>   Ramp, 
>   Ignore,
>   Particle,
>   Floor,
>   Flat,
>   Container,
>   OnRamp,
>   BufferStatic,
>   BufferDynamic
>   );
> {$scopedenums off}

I misunderstood you. I thought you wanted to use scopedenums with the
prior version.

Mattias
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Scoped enums and inferred types

[Martok]

> I doubt that many would be using scopedenums for that.
Isn't that what they're for?

{$SCOPEDENUMS ON}
type
  TTileSortingFlag = (Static,
  Ramp,
  Ignore,
  Particle,
  Floor,
  Flat,
  Container,
  OnRamp,
  BufferStatic,
  BufferDynamic
  );

As a side note, Ryan: if you need to interoperate with other languages, using
enums is dangerous. FPC has different enum storage semantics from most other
compilers, and will happily drop you into "undefined" behaviour.
Example from C# syntax:
   enum Day : byte {Sat=1, Sun, Mon, Tue, Wed, Thu, Fri};
is _not_ translated as
   {$PACKENUM 1}
   Day = (Sat=1, Sun, Mon, Tue, Wed, Thu, Fri);
Instead, write
   {$PACKENUM 1}
   Day = (_low=low(Byte), Sat=1, Sun, Mon, Tue, Wed, Thu, Fri, _hi=high(Byte));


Regards,
Martok

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Scoped enums and inferred types

[Michael Van Canneyt]

On Wed, 21 Feb 2018, Ryan Joseph wrote:





On Feb 21, 2018, at 4:09 PM, Mattias Gaertner  wrote:

I doubt that many would be using scopedenums for that.


why not? Scoped enums did clean that up a little but still lots of extra typing 
during assignments and parameters.

That compared to the previous is a still win though (less code is always a good 
thing).

{$scopedenums on}
type
TTileSortingFlag = (Static,
Ramp,
Ignore,
Particle,
Floor,
Flat,
Container,
OnRamp,
BufferStatic,
BufferDynamic
);
{$scopedenums off}


And if you use
 type
   TTileSortingFlag = (tsfStatic,
   tsfRamp,
   tsfIgnore,
   tsfParticle,
 etc. );

You don't need scoped enums at all and the problem goes away.

You create a problem, and then you demand that the compiler introduces
tricks to solve the problem you created. Where is the logic in that ?

Don't create the problem to begin with, and we can all spend our time on
something more useful.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Scoped enums and inferred types

[Ryan Joseph]

> On Feb 21, 2018, at 4:09 PM, Mattias Gaertner  
> wrote:
> 
> I doubt that many would be using scopedenums for that.

why not? Scoped enums did clean that up a little but still lots of extra typing 
during assignments and parameters.

That compared to the previous is a still win though (less code is always a good 
thing).

{$scopedenums on}
type
TTileSortingFlag = (Static, 
Ramp, 
Ignore,
Particle,
Floor,
Flat,
Container,
OnRamp,
BufferStatic,
BufferDynamic
);
{$scopedenums off}


Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Scoped enums and inferred types

[Mattias Gaertner]

On Wed, 21 Feb 2018 15:58:12 +0700
Ryan Joseph  wrote:

>[...]
> type
>   TTileSortingFlag = (kTileSortingStatic, 
>   kTileSortingRamp, 
>   kTileSortingIgnore,
>   kTileSortingParticle,
>   kTileSortingFloor,
>   kTileSortingFlat,
>   kTileSortingContainer,
>   kTileSortingOnRamp,
>   kTileSortingBufferStatic,
>   kTileSortingBufferDynamic
>   );

I doubt that many would be using scopedenums for that.

Mattias
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Scoped enums and inferred types

[Ryan Joseph]

> On Feb 21, 2018, at 3:45 PM, Mattias Gaertner  
> wrote:
> 
> I think this would be confusing:
> 
> {$scopedenums on}
> type
>   TMyType = (A, B, C);
> {$scopedenums off}
> var
>  A: integer;
> 
> procedure DoThis (t: TMyType; i: integer);
> begin
> end;
> 
> DoThis(A,A);

yes it would be. :) Swift lets you opt out if you want so you can still do 
DoThis(TMyType.A, A) in that case but more specifically Swift keeps the . 
prefix so it would be DoThis(.A, A). Not always what you want but in some cases 
it’s really handy. In many API’s there’s a constant plague of long enum names 
all starting with the same prefix so shortening them to the logical suffix when 
possible just make sense. 

Here’s something that’s all too common in code. There’s obviously some 
redundancy here we could optimize out. The only reason we keep the prefix is 
for name space integrity but logically in code what I’m really thinking about 
is the suffix so it makes sense that if the compiler could infer this it would 
save me time.

type
TTileSortingFlag = (kTileSortingStatic, 
kTileSortingRamp, 
kTileSortingIgnore,
kTileSortingParticle,
kTileSortingFloor,
kTileSortingFlat,
kTileSortingContainer,
kTileSortingOnRamp,
kTileSortingBufferStatic,
kTileSortingBufferDynamic
);


Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] fpreport rangeerrors with TFPReportColor

[Andreas Frieß]

when i compile in Lazarus the Reportdesigner with activated RangeCheck 
it gives a lot of runtimeerror with rangeerrors.


The definition is TFPReportColor  = type UInt32;

Loading and saving in JSON is done by

function ReadInteger(AName: String; ADefault: Integer): Integer; override;
function WriteInteger(AName: String; ADefault: Integer): Integer; override;

internally of write and read there is a cast from d.AsInt64 to integer.

This means you have at reading a AsInt64 -> Integer -> UInt32. Actual i 
have a value of  2147483648 ($‭8000‬) wich make a rangecheckerror :-)


Should the definition for TFPReportColor not better TFPColor ( I KNOW 
THE DIFFENCES) or QWord with the according routines. Because UInt32 is 
not a JSON dataformat. Integer seems to be to small, so QWord fits this 
better. TFPColor is more FPC-Compatible (with the overhead of the needed 
conversions).


I am wrong ?

Andreas


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Scoped enums and inferred types

[Ryan Joseph]

> On Feb 21, 2018, at 2:57 PM, Michael Van Canneyt  
> wrote:
> 
> The job of the compiler is to create correct code. Not to ensure you write 
> readable code. Every feature that is introduced
> offers more scope for abuse (generics jump to mind).

I think you may change your mind if you had to type 
NSSomeLongNameOfSomethingValueKey all day instead of .Value. Remembering prefix 
names is a waste of my time if the compiler can do it for me. I wonder how many 
hours total in my life I’ve spent writing lists of constants with prefixes and 
then typing them back out in function calls. 

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Scoped enums and inferred types

[Mattias Gaertner]

On Wed, 21 Feb 2018 09:38:17 +0700
Ryan Joseph  wrote:

>[...]Doesn’t the compiler know the type and can infer “A” is relative to the 
>scoped enum? I understand there’s a possibility for name conflicts but you 
>could just use the full name in that case.

I think this would be confusing:

{$scopedenums on}
type
TMyType = (A, B, C);
{$scopedenums off}
var
  A: integer;
 
procedure DoThis (t: TMyType; i: integer);
begin
end;
 
DoThis(A,A);

Mattias
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal