[Java] Waarom lijkt een protected var public?

[Alain]

Java:

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?

[Gropah]

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]

Zie ook de tabletjes over zichtbaarheid in de oracle java tutorial. https://docs.oracle.com/j...javaOO/accesscontrol.html

[Alain]

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?

[Gropah]

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]

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]

[Gropah]

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]

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.

[Gropah]

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]

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]

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.

[kluyze]

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]

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, Python^{voor 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

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

[Gropah]

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]

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

Ik ben blij dat ik in ieder geval iemand heb die me begrijpt.

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?

[Nick_S]

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.

[NMe]

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.

[terje7601]

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]

@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

Nick_S schreef op zondag 14 oktober 2018 @ 22:25:
Ik heb donderdag een QandA met James.

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]

[NMe]

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.

[Hydra]

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.

[Nick_S]

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

[Hydra]

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

[eamelink]

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

Java 11 is een LTS, 9 en 10 niet.

[ThomasG]

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]

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.

[Alain]

Bedankt voor jullie antwoorden. Het is me wat duidelijker geworden. Devies is mee leren leven dus.

[.oisyn]

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]

[Hydra]

.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.