'treat private like protected'

[MarkMLl]

Yes, I think that's it... thanks very much. I was having a lot of trouble with "surfacing" etc., and was hesitant about equating it with "override" since it already has a specific meaning.

So basically, that boosts a protected property up to a public one, and (presumably) there isn't a trivial/safe way of directly boosting private to protected or public (OP's question).

MarkMLl

[Thaddy]

So basically, that boosts a protected property up to a public one, and (presumably) there isn't a trivial/safe way of directly boosting private to protected or public (OP's question).

- A trivial solution is a derived class as suggested. Basic OOP and safe.
- Using fields that has getters/setters for access through a property means you should never access the field directly: that depends on the complexity of the setter/getter. Not safe.
- private has unit scope, not class scope (strict private has class scope) so you can also add a simple plain function to that unit. Safe/unsafe depending on programmers brains.
- the old hacks are not a good idea as explained above. (But I still use it in some Delphi code  ) Unsafe,
- Promotion of visibility is always possible, demotion is not (easy). Safe.

Basically the language should take offence of your remark.

[SymbolicFrank]

Oh, wow, there is a property   How did I miss that? I feel very stupid 

But, it works, so I'm happy

[SymbolicFrank]

- A trivial solution is a derived class as suggested. Basic OOP and safe.

So, if you add a public field with the same name as an inaccessible private one, does it make that field public, or does it create a new field? Testing seems to indicate the latter. Or does it has to be in the same source file to work, as private fields are accessible there?

[PascalDragon]

- A trivial solution is a derived class as suggested. Basic OOP and safe.

So, if you add a public field with the same name as an inaccessible private one, does it make that field public, or does it create a new field? Testing seems to indicate the latter. Or does it has to be in the same source file to work, as private fields are accessible there?

It will be a new field. Always. (Except in the same class, because there you can't have two fields with the same name )

[Zvoni]

- A trivial solution is a derived class as suggested. Basic OOP and safe.

So, if you add a public field with the same name as an inaccessible private one, does it make that field public, or does it create a new field? Testing seems to indicate the latter. Or does it has to be in the same source file to work, as private fields are accessible there?

Not Fields, but Properties (with Getter/Setter) Yes.
At least i understand it that way.

[Arioch]

Isn't there pre-processor in FPC like in C and unlike Delphi ?

Could preprocessor, on condition of some $IFDEF or $IFOPT, be replacing "private" with "public" in the compilation pipeline, but not in editor or on disk ?

I just remembereed a trend in newer languages like Nemerle or Scala to expose part of compiling pipeline to the sources themselves, providing for making "compiler plugins", "hygienic macros" and what not, including as part of the project itself.

[MarkMLl]

Isn't there pre-processor in FPC like in C and unlike Delphi ?

No, and don't suggest that one should be added (it's been done to death, and the developers don't like it).

There's a modest amount of conditional processing (similar to Delphi) at an early stage of compilation...

Could preprocessor, on condition of some $IFDEF or $IFOPT, be replacing "private" with "public" in the compilation pipeline, but not in editor or on disk ?

...which does have quite good single-token ("macro") expansion, i.e. can expand to multiple lines etc.

However that's not relevant in the current case, since what OP's asking about is converting the visibility of something which has been separately-compiled, i.e. a field etc. that's explicitly private nearer the root of the class tree.

MarkMLl

[Arioch]

However that's not relevant in the current case, since what OP's asking about is converting the visibility of something which has been separately-compiled

There is no BPLs in FPC yet, so from user PoV there is no "separate compilation" but all the .pas file of the project are recompiled as needed.

So, the requested functionality could be added by a compiler-global settings as dumb string replace on the tokenizer level and even before it (preprocessor).

The claimed goal is to reduce "git/svn commit log noise" and it could do.
From the user-level surface view it seems relatively low-hanging fruit.
Whether the goal is worth enough i have no opinion.

[MarkMLl]

So, the requested functionality could be added by a compiler-global settings as dumb string replace on the tokenizer level and even before it (preprocessor).

Could-could-could... the point is that it /doesn't/ and isn't going to.

Definitions, i.e. the parameter of an $ifdef, are project-level so are conveniently global. I don't believe that macros are (I might check later, but not immediately; please feel free to preempt me).

However that /still/ doesn't help OP, unless the original author of the unit he's inheriting from changes his code... and if he does there's plenty of ways better than relying on a preprocessor.

I have my own opinion on this, which I have vented plenty of times already. The bottom line is that by now FPC- even discounting the RTL etc.- is a massively complex undertaking, and we're stuck with what the core team is (rather thanklessly) maintaining and enhancing.

Later: unless my experiment misses something obvious, a macro has to be defined in the file where it's being used i.e. can't be defined at the project level.

Assuming Lazarus, a project-level option like

Code: [Select]

-dmacro_test:=''

is passed to the compiler on the command line without the quoted part but is not picked up by e.g.

Code: Pascal  [Select][+][-]

1. initialization
2.  
3. WriteLn( macro_test );
4. ...
5.  

However either of these forms works in a unit file:

Code: Pascal  [Select][+][-]

1. { define macro_test:='' }
2. {$define macro_test:= }
3.  

So it's the := in the definition that's significant, rather than the quoted parameter. And even if this /could/ be fixed the likelihood that it /will/ be fixed is vanishingly small.

MarkMLl

[PascalDragon]

However that's not relevant in the current case, since what OP's asking about is converting the visibility of something which has been separately-compiled

There is no BPLs in FPC yet, so from user PoV there is no "separate compilation" but all the .pas file of the project are recompiled as needed.

Yes, there is separate compilation, because the RTL and FCL are provided pre-compiled with the compiler installations. And also Lazarus essentially does this, because it separately compiles the Lazarus packages and only then compiles the program while only providing the units paths to the pre-compiled units.

So, the requested functionality could be added by a compiler-global settings as dumb string replace on the tokenizer level and even before it (preprocessor).

We won't add preprocessor support.