Re: [fpc-pascal] mode switch madness
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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] mode switch madness
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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] mode switch madness
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 - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] mode switch madness
> On Apr 14, 2019, at 1:29 PM, Sven Barth via fpc-pascal
> 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 - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] mode switch madness
Am 14.04.2019 um 17:03 schrieb Ryan Joseph:
On Apr 13, 2019, at 10:07 PM, Ben Grasset 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 - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] mode switch madness
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 - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] mode switch madness
On 14/04/2019 17:03, Ryan Joseph wrote:
On Apr 13, 2019, at 10:07 PM, Ben Grasset 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 - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] mode switch madness
> On Apr 13, 2019, at 10:07 PM, Ben Grasset 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 - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] mode switch madness
Someone said:
"You can do a {$i mysettings.inc}"
I give that a +1
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] mode switch madness
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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] mode switch madness
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 - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] mode switch madness
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 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] mode switch madness
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
Re: [fpc-pascal] mode switch madness
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 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 - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] mode switch madness
> 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 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] mode switch madness
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
Re: [fpc-pascal] mode switch madness
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 - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] mode switch madness
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 - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
