final protected private symbol

[Stephen R. van den Berg]

Can anyone point me to the docs (or answer it here) where it
is explained what the exact implications are of the modifiers
final, protected and private?
And, what happens if they are combined; do all permutations make sense?

[Martin Bähr]

Post by Stephen R. van den Berg
Can anyone point me to the docs (or answer it here) where it
is explained what the exact implications are of the modifiers
final, protected and private?
And, what happens if they are combined; do all permutations make sense?

it is disappointingly (byt not surprisingly) hard to search for "pike final
private protected" on google. finally found it by limiting the search to the pike website:

http://pike.lysator.liu.se/docs/tutorial/oop/access_control.xml

also, in your mail archives:
http://osdir.com/ml/lang.pike.user/2008-07/msg00004.html :-)))

there is some discussion related to this topic in july 2008 in the thread on
release preparations.

greetings, martin.

[Stephen R. van den Berg]

Post by Martin Bähr
http://osdir.com/ml/lang.pike.user/2008-07/msg00004.html :-)))

Well, I get an A for consistency. It appears that nobody answered my
questions adequately back then, and 6 years later, it's still that same
nagging feeling that I do not know enough :-). I already forgot I asked
it back then.

Rereading all the docs I now conclude the following
(anyone more knowledgeable, please speak up):

- If a member is not part of the public interface, make it private by default.
- A member that is private is already protected, local and final by
implication.
- Use protected instead of private expressly only then when subclasses
are supposed to access this member.
- Use final on all public and protected members unless they are expected
to be overridden by subclasses.

The above guidelines would result in the most efficient and compact code.

The use of local is an odd one; it's probably something that is rarely
used if ever. Does anyone have a typical example that makes sense?

[Chris Angelico]

Post by Stephen R. van den Berg
Rereading all the docs I now conclude the following
- If a member is not part of the public interface, make it private by default.
- A member that is private is already protected, local and final by
implication.
- Use protected instead of private expressly only then when subclasses
are supposed to access this member.
- Use final on all public and protected members unless they are expected
to be overridden by subclasses.
The above guidelines would result in the most efficient and compact code.

- If you've fallen in love with Python's simplicity, ignore all these
keywords and leave everything public.

Has anyone benchmarked the various keywords and seen how much
performance improvement you get? In theory, 'final' at least ought to
result in faster code, but how much?

ChrisA

[Stephen R. van den Berg]

Post by Chris Angelico

Post by Stephen R. van den Berg
The above guidelines would result in the most efficient and compact code.

- If you've fallen in love with Python's simplicity, ignore all these
keywords and leave everything public.
Has anyone benchmarked the various keywords and seen how much
performance improvement you get? In theory, 'final' at least ought to
result in faster code, but how much?

Well, for user-level-dime-a-dozen-application-level-code I agree, and
I probably wouldn't care either (unless it's a very tight loop which runs for
a very long time); but when writing library code (e.g. a pgsql driver), it
matters (even if it's only slightly).

[Martin Bähr]

Post by Stephen R. van den Berg
Can anyone point me to the docs (or answer it here) where it
is explained what the exact implications are of the modifiers
final, protected and private?

apart from the tutorial there are moree wordy explanations for each keyword in the pike book.
(btw: bill, how about releasing the book online now for free?)

Post by Stephen R. van den Berg
And, what happens if they are combined; do all permutations make sense?

probably the best answer on the last question:
from Martin Stjernholm:

Just a note: There's no reason to use both private and protected at
the same time. private is strictly more restrictive, so it implies
protected.

https://www.mail-archive.com/pike-***@lists.lysator.liu.se/msg01710.html

greetings, martin.

[Per Hedbor () @ Pike (-) importmöte för mailinglistan]

Post by Chris Angelico
Has anyone benchmarked the various keywords and seen how much
performance improvement you get? In theory, 'final' at least ought to
result in faster code, but how much?

Things marked 'final' or 'private' being faster is a new feature in
pike 8.0 (final/private global variables are accessed directly,
without using the vtable, basically).

Before there was really no difference except access rights, so the
only use was to make the API "cleaner".

Or, well, I think pike 7.8 optimized 'final constant' by having uses
of the constant use the constant directly instead of looking it up.

(This dones not affect how the constants works when they are acceessed
using the module system (there it is the index operator used that
decides if they are constant or not))

[Stephen R. van den Berg]

Post by Per Hedbor () @ Pike (-) importmöte för mailinglistan
Before there was really no difference except access rights, so the
only use was to make the API "cleaner".

And in anticipation of better optimisers in the future.

After changing most protecteds to private, I get this:

/usr/local/pike/8.0.31/lib/modules/Sql.pmod/pgsql_util.pmod:363: Warning: range_error is private but not used anywhere.
/usr/local/pike/8.0.31/lib/modules/Sql.pmod/pgsql_util.pmod:363: Warning: range_error is private but not used anywhere.

Is there a way to suppress this warning message without generating any actual
code?

The range_error() method is being called by the inherited classes. Seems like
this quite a common case, and thus its invocation cannot be detected by
the compiler.

Also, given the fact that despite the warnings, the driver seems to work
flawlessly, it is apparently a given that a member marked private
will override and be accessible to inherited classes.

[Per Hedbor () @ Pike (-) importmöte för mailinglistan]

Inherited (and inheriting) classes can not call private functions
(according to the rules).

And they are not normally accessible, the only reason for it being so
in this case is that the class (Stdio.Buffer) is written in C, and
calls the method directly by offset, without checking permissions.

[Stephen R. van den Berg]

Post by Per Hedbor () @ Pike (-) importmöte för mailinglistan
Inherited (and inheriting) classes can not call private functions
(according to the rules).

That sounds more logical.

Post by Per Hedbor () @ Pike (-) importmöte för mailinglistan
And they are not normally accessible, the only reason for it being so
in this case is that the class (Stdio.Buffer) is written in C, and
calls the method directly by offset, without checking permissions.

Ok. Changed it to protected instead. Thanks.

[Mirar @ Pike importmöte för mailinglistan]

Post by Chris Angelico
Has anyone benchmarked the various keywords and seen how much
performance improvement you get? In theory, 'final' at least ought to
result in faster code, but how much?

Good question. I thought most of those keywords was for the coder
(hence I tend to ignore them), not for the code. But some should give
improvement.