mode switch madness

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

mode switch madness

Ryan Joseph
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 specific features but it’s becoming unruly and tedious.

Even if this isn’t the best solution anything resembling a manager or wrangler would be good.

program test;

{$modeswitch-all autoderef}
{$modeswitch-all advancedrecords}
{$modeswitch-all typehelpers}
{$modeswitch-all multihelpers}
{$modeswitch-all implicitfunctionspecialization}

...


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: mode switch madness

Michael Van Canneyt


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. I really like how FPC lets us opt into specific features but it’s becoming unruly and tedious.
>
> Even if this isn’t the best solution anything resembling a manager or wrangler would be good.
>
> program test;
>
> {$modeswitch-all autoderef}
> {$modeswitch-all advancedrecords}
> {$modeswitch-all typehelpers}
> {$modeswitch-all multihelpers}
> {$modeswitch-all implicitfunctionspecialization}
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.

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: mode switch madness

schuler
I would use something like {$include mysettings.inc} .

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

Re: mode switch madness

Ryan Joseph
In reply to this post by Michael Van Canneyt


> On Apr 12, 2019, at 10:15 AM, Michael Van Canneyt <[hidden email]> 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 extension? It’s really getting out of hand now.

Problem with compiler switches is that they’re decoupled from the program itself and not documented in the actual programs source code. Honestly I’d prefer all compiler switches be stored in the program file so we didn’t have distribute extra files that contain command line arguments.

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: mode switch madness

Michael Van Canneyt


On Fri, 12 Apr 2019, Ryan Joseph wrote:

>
>
>> On Apr 12, 2019, at 10:15 AM, Michael Van Canneyt <[hidden email]> 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 extension? It’s really getting out of hand now.
I really don't think we should reconsider this.
Locality is a good rule. It keeps things predictable.

Maybe you're just using the wrong combination of options ?
I don't have a single project where I have to use modeswitches.

> Problem with compiler switches is that they’re decoupled from the program
> itself and not documented in the actual programs source code.  Honestly
> I’d prefer all compiler switches be stored in the program file so we
> didn’t have distribute extra files that contain command line arguments.

What happens if you have a third-party unit that is aversely affected by the
settings in your program ? I don't think this is a good idea.

So, I'd prefer to keep things local.

You can do a

{$i mysettings.inc}

if you really need that many options. The effect is the same.

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: mode switch madness

Michael Van Canneyt
In reply to this post by schuler


On Fri, 12 Apr 2019, Joao Schuler wrote:

> I would use something like {$include mysettings.inc} .
>

Exactly.

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: mode switch madness

Free Pascal - General mailing list
In reply to this post by Ryan Joseph
Ryan Joseph <[hidden email]> schrieb am Fr., 12. Apr. 2019, 16:37:


> On Apr 12, 2019, at 10:15 AM, Michael Van Canneyt <[hidden email]> 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 extension? It’s really getting out of hand now.

Let me think... Nope. Not the time. 

Regards, 
Sven 

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

Re: mode switch madness

Ben Grasset
I dunno about setting them globally, but generally I do find modeswitches rather annoying, as the combination of features is pretty arbitrary, and they mostly just *disallow* things that couldn't break the code of people who weren't using those features to begin with if they were allowed.

E.G, I sincerely doubt that anybody has *ever* thought, "man, I sure am glad that {$mode ObjFPC} does not allowed advanced records. It would be specifically bad if it did!" because it just doesn't matter if they weren't using advanced records to start with. It's just a lot of minor rules that nobody can really explain but that tend to add up in relatively annoying ways.

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

Re: mode switch madness

Florian Klämpfl
Am 14.04.2019 um 04:07 schrieb Ben Grasset:
> I dunno about setting them globally, but generally I do find modeswitches rather annoying, as the combination of
> features is pretty arbitrary, and they mostly just *disallow* things that couldn't break the code of people who weren't
> using those features to begin with if they were allowed.

It helps a lot to force a certain programming style.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: mode switch madness

Anthony Walter-3
In reply to this post by Ryan Joseph
Someone said:

"You can do a {$i mysettings.inc}"

I give that a +1

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

Re: mode switch madness

Ryan Joseph
In reply to this post by Ben Grasset


> On Apr 13, 2019, at 10:07 PM, Ben Grasset <[hidden email]> wrote:
>
> E.G, I sincerely doubt that anybody has *ever* thought, "man, I sure am glad that {$mode ObjFPC} does not allowed advanced records. It would be specifically bad if it did!" because it just doesn't matter if they weren't using advanced records to start with. It's just a lot of minor rules that nobody can really explain but that tend to add up in relatively annoying ways.
>

I like what Jonas did for the ObjC mode switch where he named them with versions. Maybe a {$mode objfpc2} one day.

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: mode switch madness

Jonas Maebe-3
On 14/04/2019 17:03, Ryan Joseph wrote:
>
>
>> On Apr 13, 2019, at 10:07 PM, Ben Grasset <[hidden email]> wrote:
>>
>> E.G, I sincerely doubt that anybody has *ever* thought, "man, I sure am glad that {$mode ObjFPC} does not allowed advanced records. It would be specifically bad if it did!" because it just doesn't matter if they weren't using advanced records to start with. It's just a lot of minor rules that nobody can really explain but that tend to add up in relatively annoying ways.
>>
>
> I like what Jonas did for the ObjC mode switch where he named them with versions.

That was because Apple did the same with the Objective-C language:
https://en.wikipedia.org/wiki/Objective-C#Objective-C_2.0 :)


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

Re: mode switch madness

Free Pascal - General mailing list
In reply to this post by Ben Grasset
Am 14.04.2019 um 04:07 schrieb Ben Grasset:

> I dunno about setting them globally, but generally I do find
> modeswitches rather annoying, as the combination of features is pretty
> arbitrary, and they mostly just *disallow* things that couldn't break
> the code of people who weren't using those features to begin with if
> they were allowed.
>
> E.G, I sincerely doubt that anybody has *ever* thought, "man, I sure
> am glad that {$mode ObjFPC} does not allowed advanced records. It
> would be specifically bad if it did!" because it just doesn't matter
> if they weren't using advanced records to start with. It's just a lot
> of minor rules that nobody can really explain but that tend to add up
> in relatively annoying ways.
The thing is that we do try to be backwards compatible and thus rather
conservative with mode ObjFPC. E.g. the following code compiles without
the modeswitch set, but not with:

=== code begin ===

program tmw;

{$mode objfpc}

type
   TTest = record
     private: LongInt;
     public: LongInt;
     protected: LongInt;
     strict: Longint;
   end;

begin

end.

=== code end ===

This hasn't always been done optimally in the past, e.g. when I added
class helper support back in '12 or so I didn't protect the changes
behind a modeswitch. Something I would not do today.

Also the modeswitch itself is definitely required as definitely not all
language modes should support advanced records by default (e.g. TP or ISO).

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

Re: mode switch madness

Free Pascal - General mailing list
In reply to this post by Ryan Joseph
Am 14.04.2019 um 17:03 schrieb Ryan Joseph:
>
>> On Apr 13, 2019, at 10:07 PM, Ben Grasset <[hidden email]> wrote:
>>
>> E.G, I sincerely doubt that anybody has *ever* thought, "man, I sure am glad that {$mode ObjFPC} does not allowed advanced records. It would be specifically bad if it did!" because it just doesn't matter if they weren't using advanced records to start with. It's just a lot of minor rules that nobody can really explain but that tend to add up in relatively annoying ways.
>>
> I like what Jonas did for the ObjC mode switch where he named them with versions. Maybe a {$mode objfpc2} one day.
My idea was to maybe add a mode ObjFPCExt or ObjFPCAdv which is quite a
bit less conservative and might break backwards compatibility a bit more
often when new features are added.

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

Re: mode switch madness

Ryan Joseph


> On Apr 14, 2019, at 1:29 PM, Sven Barth via fpc-pascal <[hidden email]> wrote:
>
>> I like what Jonas did for the ObjC mode switch where he named them with versions. Maybe a {$mode objfpc2} one day.
> My idea was to maybe add a mode ObjFPCExt or ObjFPCAdv which is quite a bit less conservative and might break backwards compatibility a bit more often when new features are added.

That’s a good idea to make a place we can add new mode switches for new language features which 99% of people are going to use. Most mode switches don’t break backwards compatibility but the pending multi-helpers could certainly cause some problems. Array operators could also but can’t think of any others.

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: mode switch madness

wkitty42
In reply to this post by Anthony Walter-3
On 4/14/19 9:08 AM, Anthony Walter wrote:
> Someone said:
>
> "You can do a {$i mysettings.inc}"
>
> I give that a +1


FWIW: all of the delphi code that i've worked with trying to port to FPC has had
this... at least one had an include file that IFDEF'd its way through like 4 or
5 other pascal compilers... to me, once i saw this and realized what it was
doing, this seems like the best way and also to be the pascal way...


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

Re: mode switch madness

Zoë Peterson
In reply to this post by Jonas Maebe-3
On 4/14/2019 10:41 AM, Jonas Maebe wrote:
> That was because Apple did the same with the Objective-C language:
> https://en.wikipedia.org/wiki/Objective-C#Objective-C_2.0 :)

How does $modeswitch objectivec1 differ from objectivec2?  That article
mentions that Objective-C 2.0 added 64-bit support, but we've only had
objectivec1 enabled and our 64-bit builds appear to be working without
issue?

--
Zoë Peterson
Scooter Software

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

Re: mode switch madness

Jonas Maebe-3
On 15/04/2019 17:19, Zoë Peterson wrote:
> On 4/14/2019 10:41 AM, Jonas Maebe wrote:
>> That was because Apple did the same with the Objective-C language:
>> https://en.wikipedia.org/wiki/Objective-C#Objective-C_2.0 :)
>
> How does $modeswitch objectivec1 differ from objectivec2?  That article
> mentions that Objective-C 2.0 added 64-bit support, but we've only had
> objectivec1 enabled and our 64-bit builds appear to be working without
> issue?

Objective-C 2.0 also language features that rely on run time support
(which is only available in the Objective-C 2.0 runtime). In FPC, the
only extra difference is that fast enumerations are supported through
the "for .. in" syntax if that mode is enabled. It indeed does not make
any difference as far as 32/64 bit support is concerned.


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal