Wspólne określenie na metody "private" i "protected", oprócz non-public?

@LukeJL czytałem wszystkie strony z synonimami zanim założyłem ten wątek i nic ciekawego tam nie znalazłem - stąd pytanie na forum.

somekind napisał(a):

shy
retarded

Shy jest spoko.

A jaki jest kontekst tego pytania w ogóle? Bo fajnie się wymyśla słowa, ale też nie wiem, po co ci to potrzebne.

Jeśli do opisania dokumentacji swojej biblioteki, to myślę, że warto używać słów, które się zadomowiły w społeczności programistów danego języka ew. coś prostego/bezpośredniego jak np. internal, non-public. bez udziwnień.

Chyba, że tworzysz własny język programowania, wtedy moim zdaniem jest sens poszaleć.

LukeJL napisał(a):

A jaki jest kontekst tego pytania w ogóle? Bo fajnie się wymyśla słowa, ale też nie wiem, po co ci to potrzebne.

Historia pytań na forum raczej jest przeciwko mnie, ale odpowiem na pytanie.

Piszę tool do automatycznego wersjonowania API w języku programowania, ma wykrywać niekompatybilne wstecz zmiany i failować build; a przepuszczać zmiany kompatybilne wstecz. Taki jest cały zamysł projektu, i działa spoko.

Naturalnie, tool działa w taki sposób, że zwraca uwagę na publiczne metody, i zakłada że metody private i protected nie są nigdy częścią interfejsu biblioteki (i od razu odpowiadam "ale przecież protected mógłby być częścią interfejsu, jak klasy abstrakcyjne, bla, bla" - to nie, tool jest tylko do metod publicznych, tak to zaprojektowałem i nie będę tego zmieniał). Z tej uwagi, 99% kodu który obsługuje metody prywatne i publiczne jest właściwie taki sam (są pewne różnice, np w message'ach, parserze, etc, ale to szczegóły). Tool parsuje te metody, bo jeśli ktoś spróbuje je wersjonować, to tool wtedy powie "te metody nie są wspierane".

Z uwagi na to że tak ogromna masa kodu ogarnia jednocześnie metody protected i private, a druga połowa publiczne metody; stąd chciałbym mieć dwa słowa na to. Na razie w kodzie mam Public i NonPublic, jest to słabe z wielu powodów. Po pierwsze, uważam że aplikacja byłaby lepiej napisana i czytelniejsza, gdyby można było określić jedno słowo bez negacji. Po drugie wyszukiwanie jest trudne, bo jak szukam "public" to oczywiście znajduje mi też NonPublic, i muszę używać regexpa żeby je wykluczyć. Po trzecie "NonPublic" brzmi jak pewne przeciwieństwo "public", a to nie o to chodzi w tym programie, chodzi o to że te metody są po prostu handlowane w różny sposób. Na początku nazwałem te metody ProtectedAndPrivate, ale było to zbyt długie i uciążliwe, i na razie jest "NonPublic".

Cały program rozwijam już jakieś pół roku, przemyślałem go na dziesiątą stronę, i jestem zadowolony z całego designu. Szukałem takich nazw na własną rękę właściwie od początku działania tego programu, synonimy też przeszukałem kilka raz. Ostatecznie nie znalazłem nic sensownego, więc ostatnią deska ratunku jest forum, burza mózgów, może ktoś rzuci coś sensownego.

Jednak wiem jak działa forum, i wiem że po tym co teraz napisałem zaraz zlecą się forumowicze i zamiast odpowiedzieć na pytanie (czyli "słowo agregujące protected i private") zaczną próbować obejść problem, i wyliczać jak bardzo tool który pisze nie ma sensu; byleby się tylko wypowiedzieć; pewnie zaraz padnie jakiś zarzut o X/Y, i pewnie jeszcze pare innych rzeczy.

Na razie faworytami są: "secret" od @LukeJL, "latent" od @dmw oraz "shy" od @somekind. Czekam jeszcze pare dni, może ktoś rzuci jakieś super określenie, jak nie to wybiorę jedno z nich.

LukeJL napisał(a):

Jeśli do opisania dokumentacji swojej biblioteki, to myślę, że warto używać słów, które się zadomowiły w społeczności programistów danego języka ew. coś prostego/bezpośredniego jak np. internal, non-public. bez udziwnień.

Nie, w dokumentacji są użyte słowa normalnie "protected and private methods".

a nie możesz zrobić 3 booleanów gdzieś, gdzie każdy boolean decydowałby o tym, czy uwzględniać (private | protected | public)?

no i jak działa ten tool od strony użytkowania? To jest część jakiegoś build systemu, narzędzie CLI, biblioteka programistyczna, apka z GUI?

Jeśli ta apka ma gdzieś możliwość konfiguracji, to można by zrobić tak:

"show": {
  "private": true,
  "protected": true,
  "public": false
}

ew.

"show": ["protected", "private"],

czy:

"hide": ["public"]

Po drugie wyszukiwanie jest trudne, bo jak szukam "public" to oczywiście znajduje mi też NonPublic, i muszę używać regexpa żeby je wykluczyć

Czyli robisz własną wyszukiwarkę do tego?

a musisz szukać po tekście, nie możesz po booleanach?

poza tym też można by zrobić jakiś minijęzyk do wyszukiwań:

someProperty public:false

nawiasem mówiąc kiedyś zrobiłem coś podobnego (ale nie z public/protected/private, tylko z możliwością semantycznego szukania zmiennych/funkcji/klas w projekcie).

LukeJL napisał(a):

a nie możesz zrobić 3 booleanów gdzieś, gdzie każdy boolean decydowałby o tym, czy uwzględniać (private | protected | public)?

no i jak działa ten tool od strony użytkowania? To jest część jakiegoś build systemu, narzędzie CLI, biblioteka programistyczna, apka z GUI?

Jeśli ta apka ma gdzieś możliwość konfiguracji, to można by zrobić tak:

"show": {
  "private": true,
  "protected": true,
  "public": false
}

ew.

"hide": {
   "public"
}

Po drugie wyszukiwanie jest trudne, bo jak szukam "public" to oczywiście znajduje mi też NonPublic, i muszę używać regexpa żeby je wykluczyć

Czyli robisz własną wyszukiwarkę do tego?

a musisz szukać po tekście, nie możesz po booleanach?

poza tym też można by zrobić jakiś minijęzyk do wyszukiwań:

someProperty public:false

nawiasem mówiąc kiedyś zrobiłem coś podobnego (ale nie z public/protected/private, tylko z możliwością semantycznego szukania zmiennych/funkcji/klas w projekcie).

haha no i dokładnie o tym mówiłem :D

Całkowite odejście od tematu, byleby tylko nie zmierzyć się z najtrudniejszą częścią, czyli znalezienie nazwy agregującej protected i private. Dlatego własnie od początku nie chciałem o tym pisać, bo nie chciałem spowodować takiego odbiegania od tematu.

@LukeJL: Na prawdę bardzo Ci dziękuję za wiele słów które zaproponowałeś, zwłaszcza "secret" jest super; ale tutaj na prawdę moja potrzeba odpowiedzi od forumowiczów się kończy - jeśli rozwiązaniem byłby wszelkiego rodzaje refaktor albo zmiana działania programu, to wpadłbym na to sam już dawno temu.

Z jakiegoś powodu ludzie mają z tym problem - podobnie było w moim temacie z kolejnością plików w folderze; i mimo że powtarzałem 10 raz "szukam rozwiązań bez sortowania", to i tak 95% odpowiedzi sugerowało sortowanie.

PS: @LukeJL No i widzisz, stało się dokładnie to o czym mówiłem - odciągnięcie dyskusji na poboczne tory.

Na razie faworytami są: "secret" od @LukeJL, "latent" od @dmw oraz "shy" od @somekind. Czekam jeszcze pare dni, może ktoś rzuci jakieś super określenie, jak nie to wybiorę jedno z nich.

Ale dlaczego "shy"...? Ze wszystkich dotychczasowo zaproponowanych terminów ten chyba brzmi najmniej technicznie. Jakbym gdzieś zobaczył, że klasa ma nieśmiałe metody to w życiu bym nie wpadł o co może chodzić.

Spearhead napisał(a):

Ale dlaczego "shy"...?

Jako, że problem postawiony w wątku jest absurdalny, bo sam pomysł jego rozwiązywania doprowadzić może jedynie do większej liczby problemów, to nawet nie dziwi mnie, że ta moja, całkowicie absurdalna propozycja, znalazła się w czołówce.

somekind napisał(a):

Spearhead napisał(a):

Ale dlaczego "shy"...?

Jako, że problem postawiony w wątku jest absurdalny, bo sam pomysł jego rozwiązywania doprowadzić może jedynie do większej liczby problemów, to nawet nie dziwi mnie, że ta moja, całkowicie absurdalna propozycja, znalazła się w czołówce.

Aha, czyli jak napisałem całą aplikację w pół roku, działa i ma się dobrze, ale w jej kodzie źródłowym występują nazwy "NonPublic", to to jest spoko. Ale jak chcę znaleźć inną nazwę na te dwie rzeczy, żeby kod był bardziej czytelny to to już jest nie spoko? Błagam.

Owszem, bo każdy wie, co to znaczy non-public. Jakakolwiek inna nazwa będzie wymagała wyjaśniania o co chodzi. I każdy stwierdzi, że autora pogrzało, że zamiast używać znanego żargonu wymyśla jakiś swój.

somekind napisał(a):

Owszem, bo każdy wie, co to znaczy non-public. Jakakolwiek inna nazwa będzie wymagała wyjaśniania o co chodzi. I każdy stwierdzi, że autora pogrzało, że zamiast używać znanego żargonu wymyśla jakiś swój.

No, nie przeczę.

Dlatego jeśli nie znajdę innego lepszego określenia, to zostanie w kodzie non-public, z powodów które wymieniłeś. Ale głupotą byłoby nie poszukać innej nazwy, bo non-public też ma swoje wady. Po pierwsze jest dwoma słowami, po drugie ma negacje, po trzecie ciężej się wyszukuje samo "public", bo trzeba zrobić regex. Jeśli jakiś z odpowiadających rzuci nazwę która będzie odpowiednia to tak nazwę metody; jak nie to zostanie non-public. Tak chyba zrobiłaby każda racjonalnie myśląca osoba - no, chyba że nie obchodzi jej dobre nazewnictwo.

Nie rozumiem ktokolwiek miałoby mieć problem z tym, że jeden forumowicz zadaje pytanie na forum o jakąś nazwę?

Riddle napisał(a):

Nie rozumiem ktokolwiek miałoby mieć problem z tym, że jeden forumowicz zadaje pytanie na forum o jakąś nazwę?

Ale ktoś tu ma problem z tym, że zadałeś pytanie? WTF.

somekind napisał(a):

Owszem, bo każdy wie, co to znaczy non-public. Jakakolwiek inna nazwa będzie wymagała wyjaśniania o co chodzi. I każdy stwierdzi, że autora pogrzało, że zamiast używać znanego żargonu wymyśla jakiś swój.

Trochę to słabo zinterpretowałeś, bo właśnie nie próbuję wymyślać - gdyby tak było to wymyśliłbym nazwę, wrzucił i koniec tematu.

Ale zauważ, że zadałem pytanie na forum dla programistów, właśnie po to żeby znaleźć nazwę która jest znana programistom. Ergo, pomysł z "wymyślaniem żargonu" chyba możemy odrzucić.

Jak piszesz kod, i chcesz zadbać o dobre nazewnictwo, to nie bierzesz pierwszej lepszej nazwy która Ci wpada do głowy, tylko zastanawiasz się nad odpowiednią nazwą, nawet jeśli to jest trudne. Jeśli Ci się uda ją znaleźć to ją bierzesz, jak nie to idziesz na kompromis np z "non-public".

somekind napisał(a):

Riddle napisał(a):

Nie rozumiem ktokolwiek miałoby mieć problem z tym, że jeden forumowicz zadaje pytanie na forum o jakąś nazwę?

Ale ktoś tu ma problem z tym, że zadałeś pytanie? WTF.

Kurcze, no nie wiem, Ty mi powiedz:

Jako, że problem postawiony w wątku jest absurdalny, bo sam pomysł jego rozwiązywania doprowadzić może jedynie do większej liczby problemów,

Riddle napisał(a):

Jako, że problem postawiony w wątku jest absurdalny, bo sam pomysł jego rozwiązywania doprowadzić może jedynie do większej liczby problemów,

Nie wiem, co w tym zdaniu było do nie zrozumienia.
o nie ja mam problem, ja po prostu przewiduję konsekwencje rozwiązania Twojego problemu poprzez zastąpienie znanego globalnie określenia jakimś wymyślonym na potrzeby jednego projektu. To tylko doprowadzi do większej liczby problemów w komunikacji. (Ale ich brak, to chyba nie jest coś, na czym Ci szczególnie zależy.)

somekind napisał(a):

Riddle napisał(a):

Jako, że problem postawiony w wątku jest absurdalny, bo sam pomysł jego rozwiązywania doprowadzić może jedynie do większej liczby problemów,

Nie wiem, co w tym zdaniu było do nie zrozumienia.
o nie ja mam problem, ja po prostu przewiduję konsekwencje rozwiązania Twojego problemu poprzez zastąpienie znanego globalnie określenia jakimś wymyślonym na potrzeby jednego projektu. To tylko doprowadzi do większej liczby problemów w komunikacji.

Skąd pomysł że będzie wymyślony na potrzeby projektu?

Takiego słowa, które nie będzie znane w środowisku i nie będzie się kojarzyło z funkcjami prywatnymi na pewno nie dodam, dlatego odrzuciłem większość propozycji tutaj. Z tego powodu odrzuciłem np internal, bo niektórym mogłoby się skojarzyć z modyfikatorem widocznym na cały pakiet.

@Riddle: skoro już rozkręcasz offtop, to potraktuj swoje posty tak samo jak mój i usuń z tego wątku.

Nadużywasz uprawnień moderatora.

Pomysły na nazwy które mi wpadły do głowy przez ten czas to dodatkowo:

• interior - ale brzmi mega dziwnie
• secluded - ale brzmi bardzo mistycznie
• covert - ale to mało znane słowo
• stealthed - brzmi jak z rpg'a
• restricted - brzmi za bardzo "restrykcyjnie"
• hidden?
• encapsulated?
• hermetic?
• scoped? (ale nie pasuje, bo public też może być scoped)

Co właściwie masz przeciwko non-public? Jest to sformułowanie, jak mi się wydaje szeroko używane w literaturze. Dla mnie najbardziej naturalne. Nad każdym z tych określeń, które przytoczyłeś, zastanawiałbym się dość długo, co właściwie autor miał na myśli. Coś jak z książkami tłumaczonymi przez Helion i ich słynnymi "budowniczymi" w odniesieniu do konstruktora.

W drugiej kolejności mając zewnętrzne API klasy, można by się pokusić o wewnętrzne (internal/inner) API, ale znowu np. w Kotlinie oznacza element klasy o zakresie modułowym, a inner kojarzy się z klasą wewnętrzną, więc może wprowadzać w błąd. Pozostałe przykłady:

• hidden - nikt ich nie ukrył, tylko nie są dostępne publicznie
• encapsulated - bardziej do niepublicznych pól klasy by się nadawało
• hermetic - kompletnie nie pasuje

piotrpo napisał(a):

Co właściwie masz przecisko non-public? Jest to sformułowanie, jak mi się wydaje szeroko używane w literaturze. Dla mnie najbardziej naturalne. Nad każdym z tych określeń, które przytoczyłeś, zastanawiałbym się dość długo, co właściwie autor miał na myśli. Coś jak z książkami tłumaczonymi przez Helion i ich słynnymi "budowniczymi" w odniesieniu do konstruktora.

Wyliczyłem już wcześniej. Idealnie by było gdyby to było jedno słowo, nie miało w sobie negacji, oraz gdyby było "searchable". Teraz nie jest, bo jak szukam "public" to znajduje mi też "nonpublic", i musze szukać regexpem żeby go wykluczyć.

Rzeczy o których nawet nie wspominałem, bo wydawały się oczywiste, to że nazwa będzie czytelna, prosta i jednoznaczna - może powinienem był to dopowiedzieć na początku, bo zarzuca mi się że to pominąłem. Są to kryteria ciężkie do spełnienia, co wyjaśnia czemu nie udało mi się znaleźć lepszej nazwy przez pół roku, i być może nawet nie istnieje.

Oczywiście jest szansa, że "non-public" to najlepsze co może być; ale jest też szansa że znajdzie się jakieś lepsze - stąd temat na forum.

piotrpo napisał(a):

W drugiej kolejności mając zewnętrzne API klasy, można by się pokusić o wewnętrzne (internal/inner) API, ale znowu np. w Kotlinie oznacza element klasy o zakresie modułowym, a inner kojarzy się z klasą wewnętrzną, więc może wprowadzać w błąd. Pozostałe przykłady:

• hidden - nikt ich nie ukrył, tylko nie są dostęne publicznie
• hermetic - kompletnie nie pasuje

No nie przeczę.

• encapsulated - bardziej do niepublicznych pól klasy by się nadawało

Logika też może być zaenkapsulowana.

Jeżeli przez pół roku i 2 g... burze w tym temacie nie udało się znaleźć czegoś odpowiedniego, to potencjalny szukający również może mieć problem, żeby wpaść na to magiczne słowo, jak już w końcu się pojawi.

Skoro poszukujesz synonimów słowa non-publc to wybierz sobie jeden np. stąd:
https://thesaurus.plus/synonyms/non-public

Który to będzie to ma zerowe znaczenie, bo wszystko inne niż non-publc będzie brzmiało równie dziwnie.

Riddle napisał(a):

Wyliczyłem już wcześniej. Idealnie by było gdyby to było jedno słowo, nie miało w sobie negacji, oraz gdyby było "searchable". Teraz nie jest, bo jak szukam "public" to znajduje mi też "nonpublic", i musze szukać regexpem żeby go wykluczyć.

To brzmi jak problem XY.

Może masz problem ze swoim workflowem? Bo to generalnie nie powinien być problem (szczególnie, że możesz ustawić opcję typu "znajduj pełne słowa", a nawet jakbyś musiał szukać regexpem, to co z tego? Czy musisz to robić co chwila w wielu różnych miejscach w kodzie, że jest to problem? Jeśli tak, to dalej pytanie - czemu?).

Ew. czegoś nie rozumiem (właśnie nie do końca łapię, co ma być searchable. Kod w projekcie?)

gajusz800 napisał(a):

Skoro poszukujesz synonimów słowa non-publc to wybierz sobie jeden np. stąd:
https://thesaurus.plus/synonyms/non-public

Który to będzie to ma zerowe znaczenie, bo wszystko inne niż non-publc będzie brzmiało równie dziwnie.

Przeczytałem to dawno temu, nic tam nie znalazłem.

Riddle napisał(a):

tool działa w taki sposób, że zwraca uwagę na publiczne metody, i zakłada że metody private i protected nie są nigdy częścią interfejsu biblioteki (i od razu odpowiadam "ale przecież protected mógłby być częścią interfejsu, jak klasy abstrakcyjne, bla, bla" - to nie, tool jest tylko do metod publicznych

Dalej szuka tego słowa?
"Unexposed" - znaczenie: "not made public"

Riddle napisał(a):

bo jeśli ktoś spróbuje je wersjonować, to tool wtedy powie "te metody nie są wspierane".

No to "Unsupported".
Riddle i tak tego nie przeczyta bo tak się sfrustrował że ukrywa moje posty :D

Z tego powodu odrzuciłem np internal, bo niektórym mogłoby się skojarzyć z modyfikatorem widocznym na cały pakiet.

Na razie faworytami są: "secret" od @LukeJL, "latent" od @dmw oraz "shy" od @somekind. Czekam jeszcze pare dni, może ktoś rzuci jakieś super określenie, jak nie to wybiorę jedno z nich.

Wcześniej wspominałeś o tym, że chcesz mieć bardziej czytelny kod. Zmienianie non-public na cokolwiek innego jedyne co zrobi to zaciemni kod, odnosząc skutek przeciwny do zamierzonego. Angielski znam, ale latent musiałem googlować.

Więc jak już idziesz w stronę zaciemniania kodu, żeby nikt inny nie wiedział o co Ci chodzi, to proponuję delitescent. Tak samo niejasne jak latent, ale przynajmniej bardziej sophisticated.
A sądząc po tym, jak chcesz zamienić coś jest dla każdego oczywistego na coś, co wyląduje w temacie "Programistyczne WTF" - proponuję pójść na całość, a nie szukać półśrodków.

A ja proponuje exoteric

ezoteryka – cecha wierzeń zwanych wiedzą tajemną, hermetyczną lub ezoteryczną i przekazywaną jedynie wybranym osobom w przeciwieństwie do dostępnej dla ogółu wiedzy egzoterycznej

dargenn napisał(a):

Z tego powodu odrzuciłem np internal, bo niektórym mogłoby się skojarzyć z modyfikatorem widocznym na cały pakiet.

Na razie faworytami są: "secret" od @LukeJL, "latent" od @dmw oraz "shy" od @somekind. Czekam jeszcze pare dni, może ktoś rzuci jakieś super określenie, jak nie to wybiorę jedno z nich.

Wcześniej wspominałeś o tym, że chcesz mieć bardziej czytelny kod. Zmienianie non-public na cokolwiek innego jedyne co zrobi to zaciemni kod, odnosząc skutek przeciwny do zamierzonego. Angielski znam, ale latent musiałem googlować.

Bardzo proszę nie filozofuj. Rozumiem że Ty takiego słowa nie znasz i nie chce Ci się szukać! Masz do tego prawo, ale oczep się bardzo proszę od tego tematu.

Powtarzałem już milion razy - jeśli znajdę odpowiednie słowo to je zamienię, jeśli nie to zostanie "non-public".

ukryty (ang. hidden)
zamaskowany (ang. masked)
zatajony (ang. suppressed)
zatuszowany (ang. covered up)
skrywany (ang. withheld)
ukryty (ang. concealed)
niewidoczny (ang. invisible)
sekretny (ang. secret)
dyskretny (ang. discreet)
niedostrzegalny (ang. imperceptible)
nieobecny (ang. absent)
nieuchwytny (ang. elusive)
osobisty (ang. personal)
ograniczony (ang. limited)
niedostępny (ang. unavailable)
tajny (ang. confidential)
chroniony (ang. safeguarded)

;)

Co złego jest w negacji? Może i wyszukiwanie będzie znajdować więcej wyników, tak jak napisałeś, ale taka nazwa jest znacznie bardziej zrozumiała dla osoby czytającej kod niż jakieś dziwne określenie, które jedynie wprawi czytającego w osłupienie.

Exclusive
Secured
Fenced
Limited
Zoned
Controlled
Bounded
Framed
Eclipsed
Cursed ;p