Jak chcielibyście żeby było oznaczone to, że w następnej wersji klasa nie będzie implementowała interfejsu?

0

Z metodami, polami i klasami sprawa jest prosta. Jak chcemy je usunąć to dodajemy @Deprecated, i potem w następnej wersji można usunąć i podbić major.

Ale co jeśli mamy klasę, którą chcemy zostawić, interfejs który chcemy zostawić, ale w następnej wersji chcemy żeby ta klasa już nie implementowała tego interfejsu?

Dajmy na to wersja 1.0.0

interface Message {
  String text();
}

class Email implements Message {
}

class Letter implements Message {
}

wypuszczamy wersję 2.0.0 i w niej mamy to

interface Message {
  String text();
}

class Email {
}

class Letter implements Message {
}

To teraz jak zrobić, żeby jakoś dać użytkownikom znać, żeby przestali używać Email jako implementacji Message?

Oczywiście można opisać "Uwaga Pany, w nastęnej wersji zrobimy że klasa X nie implementuje Y", ale może jest jakieś bardziej ustandaryzowane rozwiązanie?

7

Próbuję sobie przypomnieć taką sytuację w jakiejkolwiek z bibliotek czy frameworków, ale nie pamiętam żeby interfejs tak nagle przestał być implementowany przez jedną klasę i dalej istniał. Prędzej pamiętam żeby jeden interfejs został zastąpiony drugim i ten pierwszy był wtedy oznaczony jako deprecated przez jakiś czas.

Wydaje mi się że takie coś oznacza błąd na etapie planowania wcześniejszej wersji i nie ma na to standardu, można chyba tylko dodać do sekcji "breaking changes".

Jeżeli chodzi o bibliotekę z Twojej stopki to masz 9 otwartych issues i wszystkie stworzone przez Ciebie, więc myślę że możesz na spokojnie wprowadzać dowolne breaking changes w takiej bibliotece

1

Ja bym dał Deprecated przy metodach implementujących interfejs.

0
obscurity napisał(a):

Próbuję sobie przypomnieć taką sytuację w jakiejkolwiek z bibliotek czy frameworków, ale nie pamiętam żeby interfejs tak nagle przestał być implementowany przez jedną klasę i dalej istniał. Prędzej pamiętam żeby jeden interfejs został zastąpiony drugim i ten pierwszy był wtedy oznaczony jako deprecated przez jakiś czas.

Genialne.

Gdyby problem dotyczył po prostu usunięcia interfejsu to sprawa byłaby prosta. Ale wyraźnie napisałem w poście:

TomRiddle napisał(a):

Ale co jeśli mamy klasę, którą chcemy zostawić, interfejs który chcemy zostawić, ale w następnej wersji chcemy żeby ta klasa już nie implementowała tego interfejsu?

Zwróć uwagę na słowo klucz "interfejs który chcemy zostawić".

obscurity napisał(a):

Wydaje mi się że takie coś oznacza błąd na etapie planowania wcześniejszej wersji i nie ma na to standardu, można chyba tylko dodać do sekcji "breaking changes".

No dokładnie tak jest, i "odimplementowanie" tegoż interfejsu z całą pewnością jest breaking change; więc nie mogę tego zrobić od razu, tylko najpierw chcę je oznaczyć jako "deprecated", jakoś, i dopiero potem usunąć.

0
obscurity napisał(a):

możesz podać taki przykład z jakiejś biblioteki?

Dobrze, odejdę od tematu i znajdę kilka issuesów, żeby zaspokoić Twoją ciekawość i racjonalizację, ale wiedz że to jest schodzenie na inny temat.

https://github.com/golang/go/issues/51257
https://github.com/ipfs/go-datastore/issues/114
https://github.com/cefsharp/CefSharp/issues/3220
https://github.com/jpadilla/django-rest-framework-jsonp/issues/6
https://github.com/hyperium/h2/issues/426
https://github.com/opentracing/opentracing-java/issues/377

Jeśli jesteś już zadowolony, to proszę albo zaproponuj coś co według Ciebie jest sensownym, standardowym sposobem na oznaczenie że klasa już nie będzie implementowała interfejsu, albo nie rób off-topu, proszę.

0

od tego są komentarze. No to skoro znalazłeś przykłady to chyba możesz też zobaczyć w jaki sposób ostrzegali przed tym swoich userów i samemu możesz sprawdzić czy "jest jakieś bardziej ustandaryzowane rozwiązanie"

screenshot-20220424104350.png

Brawo dla Pana obscurity, że też wcześniej na to nie wpadłem. Szkoda tylko że w żadnym z tych issues nie ma nic takiego.

@obscurity: Prosiłem Cię o to już raz, i proszę Cię ponownie. Albo udziel się w jakiś konstruktywny sposób, dodaj opinię lub źródło które sam znalazłeś, albo się nie udzielaj wcale. Dziękuję.

1

Nie wiem czy to jest opcja w Javie, ale w C# możnaby się podpiać pod kompilator Roslyn, napisać własny analizator i strzelać konsumentom naszej libki warningami w wersjach 1.x.x do 2.0.0, że Email przestanie implementować IMessage.

0

@urke:

Czyli tak właściwie chcesz wypuścić wersję 1.x.x.(x+1) i dodać do niej jedną linijkę kodu #warning "blabla"?

0

Warning zbytnio nie różni się od tego co napisał TomRiddle w pierwszym poście

Oczywiście można opisać "Uwaga Pany, w nastęnej wersji zrobimy że klasa X nie implementuje Y", ale może jest jakieś bardziej ustandaryzowane rozwiązanie?

Tutaj analizatorkiem oznaczasz każde wystąpienie Email w solucji/castowania na wspólny interfejs.
Bardziej dosadnie się już chyba nie da.
Ale dla mnie trochu przerost formy nad treścią.

2
TomRiddle napisał(a):

No to skoro znalazłeś przykłady to chyba możesz też zobaczyć w jaki sposób ostrzegali przed tym swoich userów i samemu możesz sprawdzić czy "jest jakieś bardziej ustandaryzowane rozwiązanie"

Brawo dla Pana obscurity, że też wcześniej na to nie wpadłem. Szkoda tylko że w żadnym z tych issues nie ma nic takiego.

No to widzisz masz odpowiedź - wygląda na to że nie ma ustandaryzowanego sposobu na to. Jak chcesz to potrafisz. Wystarczyło trochę googla.
W ogóle rzadko się zdarza żeby istniał standard na poprawianie popełnionych błędów. Jak się pisze publiczną bibliotekę to powinno się włożyć kilka razy więcej czasu w analizę i projektowanie niż przy zwykłym projekcie, wtedy nie ma takich problemów

2
TomRiddle napisał(a):

To teraz jak zrobić, żeby jakoś dać użytkownikom znać, żeby przestali używać Email jako implementacji Message?

Może stworzyć nową klasę a klasę Email wyłącznie oznaczyć jako Deprecated ?

0
gosc_z_pytaniem napisał(a):
TomRiddle napisał(a):

To teraz jak zrobić, żeby jakoś dać użytkownikom znać, żeby przestali używać Email jako implementacji Message?

Może stworzyć nową klasę a klasę Email wyłącznie oznaczyć jako Deprecated ?

Dobry, pomysł, ale nie taki dobry, bo są dwa rodzaje użytkowników.

Ci którzy używają klasy Email jako Email, i Ci nie powinni nic zmieniać. Dla nich to byłaby zupełnie niepotrzebna zmiana, i oni też są w większości, 75%.
Oraz Ci którzy używają Email jako Message, i tym chcę jakoś dać znać że powinni przestać.

Deprecate całej klasy to byłoby dużo za dużo.

Jeden pomysł jaki mam to zrobić deprecate klasy Email, ale nie usuwać jej. Tylko w następnej wersji odimplementować Message i zabrać deprecate'a.

1
TomRiddle napisał(a):

Oraz Ci którzy używają Email jako Message, i tym chcę jakoś dać znać że powinni przestać.

Usuń klasę Email, zauważą od razu. Dodaj klasę EmailDupa, żeby mogli się przepiąć w miarę bezboleśnie i dodaj adnotację, że w wersji 3.0 klasa zostanie usunięta.

0

Bezsensowny zabieg dla tych którzy używają tej klasy poprawnie, nie mówiąc o tym że to całkowicie niepotrzebne.

1
TomRiddle napisał(a):

Bezsensowny zabieg dla tych którzy używają tej klasy poprawnie, nie mówiąc o tym że to całkowicie niepotrzebne.

Możesz słodzić zmianę w najbardziej wyrafinowany sposób na jaki wpadniesz, ale i tak to będzie "breaking change". Zmiana wersji w ciemno, to chyba dla narwańców bardzo dynamicznych zespołów.

Nie wiem jak inni, ale ja mam takie podejście przy podbijaniu wersji:

  1. Jak długo wersja żyje? (rok, miesiąc, 2 tygodnie?) Czy jest to wersja stabilna? Co naprawia? Czyli lektura readme/release notes/change loga/road mapy.
  2. Zastanawiam się, czy jest sens takiej zmiany
  3. Zmiana
    a) tu chciałbym, żeby mi się szybko wywaliło, najlepiej na etapie kompilacji
    b) jak się nie da, to na etapie testów

Usunięcie klasy (lub implementacji interfejsu), to jasny sygnał, że zmiana nastąpiła i trudno ją przeoczyć. Wręcz zachęta do zapoznania się z dokumentację i doszukania odpowiedzi 'Dlaczego?'.
W dokumentacji możesz dodać sekcję "Migracja z wersji X na X+1", która to wyjaśnia.

0
yarel napisał(a):
TomRiddle napisał(a):

Bezsensowny zabieg dla tych którzy używają tej klasy poprawnie, nie mówiąc o tym że to całkowicie niepotrzebne.

Możesz słodzić zmianę w najbardziej wyrafinowany sposób na jaki wpadniesz, ale i tak to będzie "breaking change". Zmiana wersji w ciemno, to chyba dla narwańców bardzo dynamicznych zespołów.

Tak, będzie.

I z tego powodu miałbym usunąć klasę zamiast zabrać z niej interfejs? Genialne, ale ja jednak podziękuję. Nie mam powodu usuwać tej klasy, więc nie usuwam.

1 użytkowników online, w tym zalogowanych: 0, gości: 1