Cookies op Tweakers

Tweakers is onderdeel van DPG Media en maakt gebruik van cookies, JavaScript en vergelijkbare technologie om je onder andere een optimale gebruikerservaring te bieden. Ook kan Tweakers hierdoor het gedrag van bezoekers vastleggen en analyseren. Door gebruik te maken van deze website, of door op 'Cookies accepteren' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt? Bekijk dan ons cookiebeleid.

Meer informatie
Toon posts:

[Java] Waarom lijkt een protected var public?

Pagina: 1
Acties:

Onderwerpen

Vraag


  • Alain
  • Registratie: oktober 2002
  • Niet online
Java:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class BaseClass {
    protected int something;
}

public class SubClass extends BaseClass {
    
}

public class ProtectedTest {

    public static void main(String[] args) {
        SubClass sc = new SubClass();
        sc.something = 123;                 // Why is this possible?
        System.out.println(sc.something);   // Why is this possible?
    }
}


Hoe kan het dat de class ProtectedTest direct naar het protected field something kan lezen en schrijven?

Blijkbaar is een protected field toegankelijk voor alle classes binnen een package, maar waarom zou je dit willen?

You don't have to be crazy to do this job, but it helps ....

Alle reacties


  • Gropah
  • Registratie: december 2007
  • Laatst online: 01:08

Gropah

Admin Softe Goederen

Oompa-Loompa 💩

Als je een library oid maakt is het best wel gewenst dat je alle classes die je zelf hebt geschreven bij die data kunnen, maar classes geschreven door mensen die je library gebruiken er niet bij kunnen.

edit: ook bij inheritance kan dit erg handig zijn

[Voor 11% gewijzigd door Gropah op 13-10-2018 21:51]


  • justahuman
  • Registratie: maart 2011
  • Laatst online: 22:50
Zie ook de tabletjes over zichtbaarheid in de oracle java tutorial. https://docs.oracle.com/j...javaOO/accesscontrol.html

  • Alain
  • Registratie: oktober 2002
  • Niet online
Gropah schreef op zaterdag 13 oktober 2018 @ 21:50:
Als je een library oid maakt is het best wel gewenst dat je alle classes die je zelf hebt geschreven bij die data kunnen, maar classes geschreven door mensen die je library gebruiken er niet bij kunnen.

edit: ook bij inheritance kan dit erg handig zijn
Ik kan je voorbeeld volgen, maar het idee achter protected is toch juist dat alleen subclasses erbij kunnen?

You don't have to be crazy to do this job, but it helps ....


  • Gropah
  • Registratie: december 2007
  • Laatst online: 01:08

Gropah

Admin Softe Goederen

Oompa-Loompa 💩

Alain schreef op zaterdag 13 oktober 2018 @ 21:53:
[...]


Ik kan je voorbeeld volgen, maar het idee achter protected is toch juist dat alleen subclasses erbij kunnen?
Als we naar de tutorial van Oracle kijken staat duidelijk dat Class, Subclass en Package er bij kunnen. Dus package private en subclasses (die niet per se in zelfde class zitten). Lijkt mij redelijk duidelijk

  • Alain
  • Registratie: oktober 2002
  • Niet online
Gropah schreef op zaterdag 13 oktober 2018 @ 21:56:
[...]


Als we naar de tutorial van Oracle kijken staat duidelijk dat Class, Subclass en Package er bij kunnen. Dus package private en subclasses (die niet per se in zelfde class zitten). Lijkt mij redelijk duidelijk
Ik vraag me ook niet af óf het zo is. Ik vraag me af wáárom het zo is. Hiermee haal je toch het hele idee achter protected weg?

[Voor 38% gewijzigd door Alain op 13-10-2018 22:02]

You don't have to be crazy to do this job, but it helps ....


  • Gropah
  • Registratie: december 2007
  • Laatst online: 01:08

Gropah

Admin Softe Goederen

Oompa-Loompa 💩

Alain schreef op zaterdag 13 oktober 2018 @ 22:01:
[...]


Ik vraag me ook niet af óf het zo is. Ik vraag me af wáárom het zo is. Hiermee haal je toch het hele idee achter protected weg?
Misschien volg ik iets niet maar laat ik het omdraaien. Wat is volgens jou het idee achter protected?

Eerder zei je dat je dacht dat alleen subclasses er bij konden, maar waarom denk je dat? En wat zou het voordeel zijn van dat tov de huidige implementatie?

  • Alain
  • Registratie: oktober 2002
  • Niet online
Gropah schreef op zaterdag 13 oktober 2018 @ 22:08:
[...]


Wat is volgens jou het idee achter protected?
Een waarde of functie waar alleen subclasses bij kunnen.
Eerder zei je dat je dacht dat alleen subclasses er bij konden, maar waarom denk je dat?
Omdat ik het zo geleerd heb.
En wat zou het voordeel zijn van dat tov de huidige implementatie?
Ik denk dat je nu vraagt waarom we überhaupt private, protected en public onderscheiden van elkaar.

Voorbeeld: Een base class kan uit alleen getters bestaan, terwijl een sub class enige setters heeft.

You don't have to be crazy to do this job, but it helps ....


  • Gropah
  • Registratie: december 2007
  • Laatst online: 01:08

Gropah

Admin Softe Goederen

Oompa-Loompa 💩

Alain schreef op zaterdag 13 oktober 2018 @ 22:24:
[...]


Een waarde of functie waar alleen subclasses bij kunnen.


[...]


Omdat ik het zo geleerd heb.
Om heel bot te zijn: dan heb je het verkeerd geleerd. Er is documentatie vanuit de maker van de taal die je iets anders verteld. Je hebt zelf een voorbeeld waaruit blijkt dat wat je hebt geleerd niet overeenkomt met de praktijk.
Ik denk dat je nu vraagt waarom we überhaupt private, protected en public onderscheiden van elkaar.
Nee, ik vraag wat het voordeel is van een access modifier wilt hebben die toegang enkel voor subclasses mogelijk maakt.

  • Voxyn
  • Registratie: april 2009
  • Laatst online: 20-06 23:36
OP: ik vermoed dat je andere talen dan Java kent, in bijvoorbeeld .net werkt protected zoals jij beschreef.

Bron:https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/access-modifiers

  • Alain
  • Registratie: oktober 2002
  • Niet online
Gropah schreef op zaterdag 13 oktober 2018 @ 23:24:
[...]


Om heel bot te zijn: dan heb je het verkeerd geleerd. Er is documentatie vanuit de maker van de taal die je iets anders verteld. Je hebt zelf een voorbeeld waaruit blijkt dat wat je hebt geleerd niet overeenkomt met de praktijk.
Nogmaals, ik begrijp wel dát het zo werkt. Ik snap alleen niet wáárom het zo werkt. Ik zie wel in dat een protected-within-package handig kán zijn, maar zie het doel van een protected toch anders.
Voxyn schreef op zaterdag 13 oktober 2018 @ 23:32:
OP: ik vermoed dat je andere talen dan Java kent, in bijvoorbeeld .net werkt protected zoals jij beschreef.
Ik ben dit inderdaad niet gewend uit andere talen.

You don't have to be crazy to do this job, but it helps ....


  • kluyze
  • Registratie: augustus 2004
  • Niet online
Gropah schreef op zaterdag 13 oktober 2018 @ 21:50:
Als je een library oid maakt is het best wel gewenst dat je alle classes die je zelf hebt geschreven bij die data kunnen, maar classes geschreven door mensen die je library gebruiken er niet bij kunnen.
Als je een lib gebruikt kan je best makkelijk bij 'package private' properties. Het enige wat nodig is, is een class in dezelfde package, wat simpel kan door een package te voorzien met dezelfde naam.

Ik ben ook nooit een fan geweest van access binnen een package.

  • RobIII
  • Registratie: december 2001
  • Laatst online: 02:30

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

Gropah schreef op zaterdag 13 oktober 2018 @ 23:24:
[...]


Om heel bot te zijn: dan heb je het verkeerd geleerd.
Om heel bot te zijn: niks verkeerd geleerd en het is helemaal niet zo raar dat TS dat denkt. In andere talen is dat namelijk wél het geval. In ieder geval in C#, PHP, Pythonvoor zover er überhaupt sprake is van access modifiers; het is meer 'convention', C++, VB.Net, Ruby, Delphi, en ik meen zélfs in Simula (de "eerste OOP taal") en zo zijn er vast nog legio voorbeelden. Dus zo raar is 't niet als iemand 't "zo geleerd heeft" en misschien moet je er dan ietsjes minder hard tegenin gaan ;) :> Java is in dit geval écht wel de vreemde eend in de bijt :>

En @Alain; zo haal je inderdaad, ook wat mij betreft, het idee achter protected onderuit. Het blijft echter beperkt binnen de package; dat is dan nog een lichtpuntje aan de horizon :P

[Voor 37% gewijzigd door RobIII op 14-10-2018 00:57]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Roses are red Violets are blue, Unexpected ‘{‘ on line 32.

Over mij


  • Gropah
  • Registratie: december 2007
  • Laatst online: 01:08

Gropah

Admin Softe Goederen

Oompa-Loompa 💩

RobIII schreef op zondag 14 oktober 2018 @ 00:26:
[...]

Om heel bot te zijn: niks verkeerd geleerd en het is helemaal niet zo raar dat TS dat denkt. In andere talen is dat namelijk wél het geval. In ieder geval in C#, PHP, Python, C++ en zo zijn er vast nog legio voorbeelden. Dus zo raar is 't niet als iemand 't "zo geleerd heeft" en misschien moet je er dan ietsjes minder hard tegenin gaan ;) :> Java is in dit geval écht wel de vreemde eend in de bijt :>
noted

Gezien het topic expliciet met java was getagd en dit soort vragen vaak door beginnende programmeurs worden gesteld deed ik de aanname dat het idee van access modifiers onbekend was. En ja, assumptions are the mother of all fuck ups

  • Alain
  • Registratie: oktober 2002
  • Niet online
RobIII schreef op zondag 14 oktober 2018 @ 00:26:
En @Alain; zo haal je inderdaad, ook wat mij betreft, het idee achter protected onderuit. Het blijft echter beperkt binnen de package; dat is dan nog een lichtpuntje aan de horizon :P
Ik ben blij dat ik in ieder geval iemand heb die me begrijpt. B)

Maar er moet toch iemand zijn opgestaan die zegt: "Laten we dat hele protected verhaal eens helemaal anders implementeren". Daar moet toch een goede reden voor zijn. Zeker om een heel ontwikkelteam mee te krijgen?

Wie o wie kan mij vertellen waarom?

You don't have to be crazy to do this job, but it helps ....


  • Nick_S
  • Registratie: juni 2003
  • Laatst online: 21:01

Nick_S

++?????++ Out of Cheese Error

Ik heb donderdag een QandA met James. Ik zou het hem eens kunnen vragen. :-D

En met Java Modules heb je tegenwoordig een stuk meer zeggenschap over wat er wel en niet zichtbaar is.

'Nae King! Nae quin! Nae Laird! Nae master! We willna' be fooled agin!'


  • NMe
  • Registratie: februari 2004
  • Laatst online: 21:59

NMe

Quia Ego Sic Dico.

Alain schreef op zondag 14 oktober 2018 @ 21:49:
[...]

Wie o wie kan mij vertellen waarom?
Ik kan er wel naar raden: de protected scope is vooral bedoeld als bescherming tegen gebruik van buitenaf op een ongeëigende manier. Degene die dit lumineuze idee had moet gedacht hebben dat een package altijd gemaakt wordt door dezelfde persoon of in elk geval hetzelfde team en die zouden normaal gesproken moeten weten hoe ze met die property om moeten gaan. Ik vind het een vrij zwak argument verder, helemaal omdat het afwijkt van waarschijnlijk letterlijk alle andere talen, maar dat is de enige reden die ik kan verzinnen.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.


  • terje7601
  • Registratie: september 2009
  • Laatst online: 07-04 10:06
Zelf vind ik het logisch/makkelijk redeneren dat elke modifier een strikte superset is van de vorige: public > protected > package > private

En stel dat protected zou betekenen "enkel subclasses", dan kan je er binnen (en buiten) dat package sowieso aan m.b.v. een subklasse die je definieert, dus die beperking biedt sowieso geen extra bescherming.

  • Hydra
  • Registratie: september 2000
  • Laatst online: 18:02
@Alain Je hebt gewoon helemaal gelijk. Het is een van de vele rare keuzes die de language designers ooit gemaakt hebben, waar we nu niet meer vanaf komen. Je kunt niet 'even' dit ongedaan maken; Java heeft altijd als doel zoveel mogelijk backwards compatible te maken. Java heeft wel meer van dit soort wratten; de originele collections zijn bijvoorbeeld compleet deprecated.

Een vand designers, James Goslin, is toevallig in Nederland voor een Meetup dus je zou het 'em zelf kunnen vragen ;)
Je bedoelt dat je naar de Blue4IT meetup gaat ;)
terje7601 schreef op maandag 15 oktober 2018 @ 09:24:
Zelf vind ik het logisch/makkelijk redeneren dat elke modifier een strikte superset is van de vorige: public > protected > package > private
Dat is vermoedelijk de redenatie geweest. Maar als je een library bouwt, is het jouw fijn om je implementatie classes volledig 'geheim' te kunnen houden. En mensen kunnen door nare shit te doen (split packages) bij je interne zooi komen. Daar zijn ze nu met Java 9 eindelijk paal en perk mee aan het stellen, maar het heeft enorm lang geduurd voordat ze zo ver waren. En die accessors zelf kunnen ze, ivm backward compatibility, niet aanpassen.

[Voor 30% gewijzigd door Hydra op 15-10-2018 09:59]

https://niels.nu


  • NMe
  • Registratie: februari 2004
  • Laatst online: 21:59

NMe

Quia Ego Sic Dico.

Hydra schreef op maandag 15 oktober 2018 @ 09:57:
En die accessors zelf kunnen ze, ivm backward compatibility, niet aanpassen.
Natuurlijk wel, kost alleen wat meer moeite. Java 9 in een LTS-traject zetten straks en Java 10 wat breaking changes meegeven. Dat niet doen zou eerder onwil zijn dan dat het niet mogelijk is.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.


  • Hydra
  • Registratie: september 2000
  • Laatst online: 18:02
NMe schreef op maandag 15 oktober 2018 @ 11:10:
Natuurlijk wel, kost alleen wat meer moeite. Java 9 in een LTS-traject zetten straks en Java 10 wat breaking changes meegeven. Dat niet doen zou eerder onwil zijn dan dat het niet mogelijk is.
Nouja, alles kan natuurlijk. Gaat alleen niet gebeuren; het is een bewuste keuze dit soort dingen compatible te houden. De Vector collection zit er ook nog steeds in. Het is zeldzaam (zie Applets bijvoorbeeld) dat dingen echt verwijderd worden.

https://niels.nu


  • Nick_S
  • Registratie: juni 2003
  • Laatst online: 21:01

Nick_S

++?????++ Out of Cheese Error

Hydra schreef op maandag 15 oktober 2018 @ 09:57:

Een vand designers, James Goslin, is toevallig in Nederland voor een Meetup dus je zou het 'em zelf kunnen vragen ;)
[...]
Je bedoelt dat je naar de Blue4IT meetup gaat ;)
Yep, m'n werkgever organiseert de meetup, dus we waren al even met collega's in overleg of we wat leuke vragen hadden voor de QandA aan het eind. En als je nog mocht willen komen, moet ik je helaas teleurstellen, er staan er nog zo'n 150 voor je in de wachtrij. Deze meetup was weer zeer populair. :-D

'Nae King! Nae quin! Nae Laird! Nae master! We willna' be fooled agin!'


  • Hydra
  • Registratie: september 2000
  • Laatst online: 18:02
Nick_S schreef op maandag 15 oktober 2018 @ 19:31:
En als je nog mocht willen komen, moet ik je helaas teleurstellen, er staan er nog zo'n 150 voor je in de wachtrij. Deze meetup was weer zeer populair. :-D
Nee, dan had ik me wel opgegeven. Ben NLJUG lid dus krijg al die mailtjes :)

https://niels.nu


  • eamelink
  • Registratie: juni 2001
  • Laatst online: 23:14

eamelink

Droptikkels

NMe schreef op maandag 15 oktober 2018 @ 11:10:
[...]

Natuurlijk wel, kost alleen wat meer moeite. Java 9 in een LTS-traject zetten straks en Java 10 wat breaking changes meegeven. Dat niet doen zou eerder onwil zijn dan dat het niet mogelijk is.
Euhhh, Java 11 is inmiddels uit, dus laten we niet meer aan 10 gaan sleutelen :D

Java 11 is een LTS, 9 en 10 niet.

  • ThomasG
  • Registratie: juni 2006
  • Laatst online: 23:38
De annonymous en inner classes in Java zijn (of in ieder geval: waren) een compiler hack. Het wordt gecompileerd naar een losse klasse in dezelfde package, die stiekem wel bij de protected en package default methods en properties moet kunnen. De reden dat protected ook bereikbaar is in een subpackage, is omdat java geen friendship heeft zoals in C++ maar ze wel een veregelijkbare functionaliteit wouden.

Ik vind het zelf net als de "generics" in Java, een ontwerpfout.

  • bwerg
  • Registratie: januari 2009
  • Niet online

bwerg

Internettrol

NMe schreef op zondag 14 oktober 2018 @ 22:28:
Degene die dit lumineuze idee had moet gedacht hebben dat een package altijd gemaakt wordt door dezelfde persoon of in elk geval hetzelfde team en die zouden normaal gesproken moeten weten hoe ze met die property om moeten gaan. Ik vind het een vrij zwak argument verder, helemaal omdat het afwijkt van waarschijnlijk letterlijk alle andere talen
Wat, het principe van een gegroepeerd stukje code (of dat nou een package, een module, of anders heet) dat afgeschermd is naar buiten toe wijkt af van andere talen?

Dat specifiek de implementatie van packages in Java hiervoor niet voldoet, eens.

Heeft geen speciale krachten en is daar erg boos over.


  • Alain
  • Registratie: oktober 2002
  • Niet online
Bedankt voor jullie antwoorden. Het is me wat duidelijker geworden. Devies is mee leren leven dus. :)

You don't have to be crazy to do this job, but it helps ....


  • .oisyn
  • Registratie: september 2000
  • Laatst online: 23:10

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

Hydra schreef op maandag 15 oktober 2018 @ 09:57:
En die accessors zelf kunnen ze, ivm backward compatibility, niet aanpassen.
Ze kunnen er natuurlijk wel een accessor bij maken. "private protected" ofzo :)
ThomasG schreef op dinsdag 16 oktober 2018 @ 09:28:
De annonymous en inner classes in Java zijn (of in ieder geval: waren) een compiler hack. Het wordt gecompileerd naar een losse klasse in dezelfde package, die stiekem wel bij de protected en package default methods en properties moet kunnen.
Die redenatie houdt geen stand, een (non-static) nested class kan ook bij de private members van zijn parent class. De JVM snapt dus weldegelijk wat nested classes zijn, want dat is op geen enkele manier te simuleren met een non-nested class.

[Voor 53% gewijzigd door .oisyn op 17-10-2018 11:51]

You see, killbots have a preset kill limit. Knowing their weakness, I sent wave after wave of my own men at them until they reached their limit and shut down. Kif, show them the medal I won.


  • Hydra
  • Registratie: september 2000
  • Laatst online: 18:02
.oisyn schreef op woensdag 17 oktober 2018 @ 11:44:
Ze kunnen er natuurlijk wel een accessor bij maken. "private protected" ofzo :)
Yup, maar dan met een betere naam. Maar in die tijd ging de ontwikkeling sowieso langzaam; Sun heeft weinig tijd/geld in Java geinvesteerd.

https://niels.nu

Pagina: 1


Apple iPad Pro (2021) 11" Wi-Fi, 8GB ram Microsoft Xbox Series X LG CX Google Pixel 5a 5G Sony XH90 / XH92 Samsung Galaxy S21 5G Sony PlayStation 5 Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True