Scoped enums and inferred types

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Scoped enums and inferred types

Ryan Joseph-3


> On Feb 21, 2018, at 5:16 PM, Sven Barth via fpc-pascal <[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Scoped enums and inferred types

Marco van de Voort
In reply to this post by Ryan Joseph-3
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Scoped enums and inferred types

Ryan Joseph-3


> On Feb 21, 2018, at 10:18 PM, Marco van de Voort <[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Scoped enums and inferred types

Ryan Joseph-3
In reply to this post by Michael Van Canneyt


> On Feb 21, 2018, at 10:13 PM, Michael Van Canneyt <[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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  -  [hidden email]
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Scoped enums and inferred types

Marco van de Voort
In reply to this post by Ryan Joseph-3
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Scoped enums and inferred types

Benito van der Zander
In reply to this post by Free Pascal - General mailing list
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
12