Recent

Author Topic: FPC Documentation: Object/class/field/method visibility: trying to clarify  (Read 6141 times)

Researching

  • Full Member
  • ***
  • Posts: 121
'                                               '              ACCESS                       '                                               '
GLOBALDESCENDENT TYPE (EVEN IN OTHER MODULES)ONLY INSIDE the module(unit)
------------------------------------------PUBLIC (default)-------------------------------------
'#################'--------------------------PROTECTED----------------------
'#################' ' ################# ' ----PRIVATE----

AND THIS

--------------------ACCESSIBILITY------------------------------
GLOBAL +STREAMING GLOBAL descendent Types, GLOBAL- descendent Types -IN UNIT- INSIDE THE UNITCLASS ITSELF
PUBLISHED --------------------------------------------------
########PUBLIC    ----------------------------------------
################Protected ------------------------------
########################Strict protected --------------------
################################Private ----------
########################################Strict Private
   

Are these two the same??

Sorry for temporary dirty message - was experimenting how to make table here.
« Last Edit: November 16, 2018, 11:17:03 am by Researching »

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: FPC Documentation: Object/class/field/method visibility: trying to clarify
« Reply #1 on: November 16, 2018, 09:38:32 am »
Here in the Netherlands we have a saying that Cruyff once translated into English as " can't make any cheese of it", meaning what do you mean?

Anyway, all this is properly documented:
- A global - in whichever unit, but subsequent used unit unit order is important- is visible to the whole program. This goes for everything declared in the interface section of a unit or the program source itself. Note that the program file itself has always access to any global declared in any used unit.
- A local - in whichever unit - is visible only to the unit in which it is declared and is declared in the implementation section of a unit. Or declared inside a method.
- A record has three  possible visibilities for its members: strict private, private and public. strict private are members only visible to the record itself,  private record members are only accessible from within the implementation section of the unit where it is declared or the record members themselves. Public is the default and means the record members are visible throughout the whole program, but again unit order is important.
- A class has strict private, strict protected, private, protected, public and published meaning:
strict private: accessible only for the class itself
strict protected: accessible only for the class itself and any derived classes
private: only accessible from the class itself, but can be referenced to in the implementation section of the unit where the class is declared. (really legacy or an historical oversight)
protected: only accessible from the class itself and derived classes, but also accessible from within the implementation unit where the class is declared (same historical oversight)
public: means visible and accessible anywhere in the program (but unit order applies).
published means the same as public, but in addition RTTI information is generated. (This is no longer 100% corrrect, a bit muddy). It is necessary for e.g. property editors and persistent storage in general.

Note that records can't have protected members, because there is no record inheritence so would not make sense.
From the point of view of language design strict should never have been necessary, but it will break an awful lot of code if private and protected would be strict....(give programmers a shortcut and they WILL use it!! and that happened..)
Any visibility in general to other units needs to have a reference to that unit either in the implementation section or the interface section.

Most of this can be found in the manuals. This write up is close, but still not 100% correct, so expect border cases and knit picking.... %) from the Yesbut tribe. (you know, the folks from Outlandia) mm, I should copyright that!

Oh I forgot:
classes and records can also be declared in an implementation section: in that case their use is also restricted to the unit itself.

« Last Edit: November 16, 2018, 02:23:02 pm by Thaddy »
Specialize a type, not a var.

wp

  • Hero Member
  • *****
  • Posts: 11854
Re: FPC Documentation: Object/class/field/method visibility: trying to clarify
« Reply #2 on: November 16, 2018, 09:39:40 am »
Trying to clarify something with such a confusing message?

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: FPC Documentation: Object/class/field/method visibility: trying to clarify
« Reply #3 on: November 16, 2018, 09:41:04 am »
Trying to clarify something with such a confusing message?
Yup. but you know I am the great confuser. Sometimes I can make some sense out of such things: I know how such brains work.. O:-)
Maybe @researching can tell if I am right or wrong in my interpretation
« Last Edit: November 16, 2018, 09:54:57 am by Thaddy »
Specialize a type, not a var.

Researching

  • Full Member
  • ***
  • Posts: 121
Re: FPC Documentation: Object/class/field/method visibility: trying to clarify
« Reply #4 on: November 16, 2018, 11:23:59 am »
People!! How to use normal HTML in messages?
Hey!!
[SOLVED: HTML in messages]
https://wiki.simplemachines.org/smf/Alphabetical_list_of_all_bulletin_board_codes

Is it possible (maybe ) to make this available to public?

description: Allows raw HTML to be used directly within a post.
example: [.html.]<em>Direct <del>html</del> <ins>HTML</ins> output</em>[/.html.]
Experiment:
INPUT:   [.html] current result [./html]
RESULT: current result  -( tags are being cut out)

Direct html HTML output - NOT POSSIBLE :(
« Last Edit: November 16, 2018, 11:46:30 am by Researching »

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: FPC Documentation: Object/class/field/method visibility: trying to clarify
« Reply #5 on: November 16, 2018, 11:32:25 am »
It depends on the context. If they are both about classes ten they are the same.

But since the first set misses published, I think you are comparing "objects" to "classes", which are two different things.

The strict versions are a later extension, but published was in there almost from the start.

p.s. thaddy: please count to ten before posting. If that doesn't help, count to twenty.

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: FPC Documentation: Object/class/field/method visibility: trying to clarify
« Reply #6 on: November 16, 2018, 11:49:32 am »
I can count to infinity, but that still doesn't help, Marco.
Specialize a type, not a var.

Researching

  • Full Member
  • ***
  • Posts: 121
Re: FPC Documentation: Object/class/field/method visibility: trying to clarify
« Reply #7 on: November 16, 2018, 11:49:41 am »
Marcov, thank you for monitoring the forum: personally - received a good help from your advice for being short.
In this case... Well... Grateful to Thaddy! Collecting this stuff own hands - would be hard.
Yes it is long! But!! This IS functional. This serves what forum should serve for, isn't it?
For me now - seems that some details are not meant in the documentation either!
« Last Edit: November 16, 2018, 11:51:31 am by Researching »

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9791
  • Debugger - SynEdit - and more
    • wiki
Re: FPC Documentation: Object/class/field/method visibility: trying to clarify
« Reply #8 on: November 16, 2018, 12:26:27 pm »
description: Allows raw HTML to be used directly within a post.
example: [.html.]<em>Direct <del>html</del> <ins>HTML</ins> output</em>[/.html.]
Yes raw html is disabled. Same for custom images. Embedding images (even only until moderated) could lead to offending images being displayed.
Also "move" is disabled. It doesnt help readability. / Abbr and acronym can hide spam, so not avail either
« Last Edit: November 16, 2018, 12:32:50 pm by Martin_fr »

Handoko

  • Hero Member
  • *****
  • Posts: 5130
  • My goal: build my own game engine using Lazarus
Re: FPC Documentation: Object/class/field/method visibility: trying to clarify
« Reply #9 on: November 16, 2018, 01:26:35 pm »
OOP cannot be understood by simply asking some questions.
You have to experience it yourself.

If you want quick answer about field/member visibility, then read Thaddy's post. But if you have time, these readings below will be very useful for you:
https://www.freepascal.org/docs-html/ref/refch6.html
http://wiki.freepascal.org/Programming_Using_Objects
http://wiki.freepascal.org/How_To_Write_Lazarus_Component
http://wiki.freepascal.org/Extending_the_IDE

Researching

  • Full Member
  • ***
  • Posts: 121
Re: FPC Documentation: Object/class/field/method visibility: trying to clarify
« Reply #10 on: November 16, 2018, 06:49:29 pm »
Well...
When you have knowledge and image about what exists - you can really read what needed when you need.
When you are newbie - at your own you generally have either of two choices:
- Dig whole literature ( 0.5year-2years)
- get stuck on miraculous mistake for another year.

What are people on the forum supposed to do: give solution to "unstuck".
But what Thaddy did - he gave an overview, so next time is possible to be little аutоnоmous. And this is the rarity.


marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: FPC Documentation: Object/class/field/method visibility: trying to clarify
« Reply #11 on: November 16, 2018, 06:56:18 pm »
private: only accessible from the class itself, but can be referenced to in the implementation section of the unit where the class is declared. (really legacy or an historical oversight)

One could also argue that it was a good concept, but the incessant ranting of people that come from languages without unit system eventually gave way to the "strict" variants.

This happens often. It also shows that giving in is rarely rewarding, the ranting just goes to the next item on the list that is different from C/#/++/J/# whatever. Currently the discussion is about inline variable declarations.

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: FPC Documentation: Object/class/field/method visibility: trying to clarify
« Reply #12 on: November 17, 2018, 07:59:44 am »
Strictly from systems theory private and protected do not need a rant. What may be ranting is the correction that was later necessary... I really don't see (at least I wasn't ranting) how to explain the intended behavior in any other way than I described. I am not even strictly ranting on the subject. Merely stating fact, not opinion.
Specialize a type, not a var.

440bx

  • Hero Member
  • *****
  • Posts: 3944
Re: FPC Documentation: Object/class/field/method visibility: trying to clarify
« Reply #13 on: November 17, 2018, 09:42:16 am »
When you are newbie - at your own you generally have either of two choices:
- Dig whole literature ( 0.5year-2years)
- get stuck on miraculous mistake for another year.
From what you write, I get the impression that you simply don't know where to start.  IOW, you sound like you're wondering where the beginning of that elephant is.

It doesn't take 1/2 a year to read the FPC documentation.  That said, if you really want to fully understand how the compiler works for everything it can do then, it might actually take 1/2 year.

For instance, Chapter 6 of the Free Pascal Reference Guide gives a good description of visibility specifiers.  Here it is:
Quote
[1] Private All fields and methods that are in a private block, can only be accessed in the module (i.e. unit) that contains the class definition. They can be accessed from inside the classes’ methods or from outside them (e.g. from other classes’ methods)

[2] Strict Private All fields and methods that are in a strict private block, can only be accessed from methods of the class itself. Other classes or descendent classes (even in the same unit) cannot access strict private members.

[3] Protected Is the same as Private, except that the members of a Protected section are also accessible to descendent types, even if they are implemented in other modules.

[4] Strict Protected Is the same as Protected, except that the members of a Protected section are also accessible to other classes implemented in the same unit. Strict protected members are only visible to descendent classes, not to other classes in the same unit.

[5] Public sections are always accessible. Published From a language perspective, this is the same as a Public section, but the compiler generates also type information that is needed for automatic streaming of these classes if the compiler is in the {$M+} state. Fields defined in a published section must be of class type.
Array properties cannot be in a published section

That gives you the "theory" then, you write a number of small programs (just skeletons) to play with and see how changing one thing affects another.   That does take a little bit of time but, as they say, seeing is believing. Handoko above was definitely right, nothing takes the place of building your own experience.

I don't think it would take 1/2 year to go through the entire manual, even writing small programs to test every feature .

The other thing is, you focus on what you need to know.  You neither need nor can, know everything. 

My advice to any newbie would be simply, read the manual(s), several times if needed and write as many little programs as necessary to test and understand every compiler feature that is useful to you.  Those features you think you won't use, skip them, cross that code when and if you ever need it.

I understand that the beginning is a bit frustrating but, you can learn a great deal going through the manuals methodically and systematically. When you don't understand something, you come here and ask, someone will shed light on whatever is causing you grief.

Colloquially, they simply call it live and learn.  Try to learn fast because life is short ;)  Being methodical helps accomplish that (it might even help make life longer but... that might just be wishful thinking on my part.)

HTH.



(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Researching

  • Full Member
  • ***
  • Posts: 121
Re: FPC Documentation: Object/class/field/method visibility: trying to clarify
« Reply #14 on: November 17, 2018, 10:09:33 pm »
OK... Applying to the colloquial decision (please forgive me... if too much daring):
At present: have two needs/aims... whatever.
1. Visual analysis tool (parse in - generate out)
2. DB viewer.

2 - DB viewer is almost ready in-design. Going to implement will definitely require OOP on some level... Advanced? - this is almost a freelance offer depending on time/price... (file DB, txt, csv, xml ->IN; txt, csv ->out.)

The "1" - i suppose would be needed by everyone, who works with code rearrangement. refactoring...... etc... About 15% ready in-design. And since it might be useful for all forum community -- is it stupid trying to gather some people for team developing? Or, at least, specially expressed help?  Let's say 5/7 from 10: ap to 18: pm? Like.... may be common repo + certain topic m.b. partially closed..???? monitored by some experienced profs ?
What is done: in the branch of Visual Pascal Community Edition: there are mentioned some source-codes of git, plus ex-Ess-model - Laz model.
All these are partially analised over the past two weeks.
Special interest to the init. library by Edson.

What would I need - is advice on strategy before investing time and effort in coding.

The concept is slightly unusual for diagr.software: the central level would be diagram of procedure calls. With packages diagr. above and frowchart / Nassi - lower.
This tool is intended primarily to visually understand and manage the structure of source.

OK... A crazy idea for the newbie, but... some days ago I did successful upgrade on sf.net C# project of wеb-сrаwlеr. With some regexps, and changed design of crawl.
The main problem about making this "1" proj - is the time for bug tracking, solving some stupid questions...
And the most difficult part would be the initial: after succeeding the first diagram roundtrip - the program will go to self supporting.

Is this alright to ask for support for development of this tool ?










 

TinyPortal © 2005-2018