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

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