[GotoFinal]

#java #programowanie
Huh, drobna zagadka bo jakoś natrafiłem na taki ciekawszy przypadek, mamy bibliotekę z takimi metodami w jednej klasie:

Object[] doSomething()
String doSomething();

Używamy tego w naszym kodzie i robimy costam.doSomething(), jak to się skompiluje?
A jak to się skompiluje jeśli zamiast Object/String będzie tam np int i double?

[A.....t]

@GotoFinal a to się w ogóle skompiluje? Coś mi tu nie gra

[GotoFinal]

@AwizisieAkat: ten kod z libki się nie skompiluje, ale da się taki uzyskać i JVM na to zezwala, za to używanie jest już ciekawe, to co uważasz że się nie skompiluje?

[E.....e]

@GotoFinal: co w ogole znaczy pytanie jak to sie skompiluje?

[S.....h]

@GotoFinal: Masz jakiś artykuł na to że zezwala? Poza tym: https://news.ycombinator.com/item?id=13976533 niczego nie znalazłem na ten temat.

[GotoFinal]

@Ewentualnie: no czy da się potem skompilować użycie tej metody, i która metoda zostanie zapisana jako ta do wykonania w obu przypadkach.

[GotoFinal]

@Sarseth: w JVM sygnatura metody to return type + nazwa metody + parametry, przy kompilacji każda metoda jest tak zapisywana, np:
invoke... some/pack/Type setProp (Ljava/lang/Integer;)D
some/pack/Type - miejsce metody
double setProp(Integer i) - sygnatura

Więc wystarczy że cokolwiek się różni, jednak javac nie zezwala na stworzenie niektórych kombinacji, jednak nie oznacza to że one nie działają w runtime lub że nie można ich użyć... ale kieruje się jakimiś dziwnymi

[A.....t]

@GotoFinal nie mam pojęcia, powinno się wywalić na kompilacji, ale jak jest to nie wiem, co mi przychodzi do głowy to albo można się do nich jakiś odwołać osobno albo ten Object [] to tablica wartości funkcji o tej samej sygnaturze

[E.....e]

@GotoFinal: nie wiem o czym Ty mowisz, ale jakbym mial powiedziec, to w przypadku kiedy napiszesz String zmienna = costam.doSomething() to wywola sie metoda ktora zwraca stringa, w reszcie typu object, analogicznie jak dasz int double to w zaleznosci od zmien ej.

[A.....t]

@Ewentualnie wydaje mi się, że Java aż tak inteligentna nie jest, żeby po typie zmiennej zgadywać metodę

[GotoFinal]

@AwizisieAkat: @Ewentualnie: żeby było śmieszniej dodam że kompilator eclipse zachowuje się inaczej niż javac przy takim kodzie

[Masuq0]

@GotoFinal: A-a-a-ale ich sygnatury są identyczne, to się nie skompiluje ( ͡° ʖ̯ ͡°)

[GotoFinal]

@Masuq0: nie są, jest inny return type. i nie przejmuj się jak powstał kod z biblioteki, on istnieje i tyle, i działa. to zapewnia JVM

[A.....t]

@GotoFinal czyli to jakiś 'undefined behavior' xd

[Masuq0]

@GotoFinal:

The compiler does not consider return type when differentiating methods, so you cannot declare two methods with the same signature even if they have a different return type.

[GotoFinal]

@AwizisieAkat: kompilator eclipse nigdy nie był zbyt zgodny z specyfikacją, więc to raczej bug eclipse, ale zachowanie javyc i tak jest dość dziwne...

[GotoFinal]

@Masuq0: huh, no ale taki kod może istnieć w JVM, czemu zastanawiasz się nad kodem który już jest skompliowany, w nie ważne jaki sposób? pytanie jest niżej, co kiedy tego użyjemy.
(PS: używając kotlina da się stworzyć 2 metody z innym return type)

[Masuq0]

@GotoFinal: Zapodaj linka jeśli możesz do takiej skompilowanej klasy która ma podobne metody (PS: masz jakiś przykład jak wygląda bytecode po skompilowaniu w kotlinie?)

[afe1]

@GotoFinal: a skad ja mam wiedziec? :P

android?
Jesli tak to link wrzucony przez @Sarseth wyjasnia sprawe

[GotoFinal]

@Masuq0:
kotlin: https://gist.github.com/GotoFinal/874746d6a58be07534b2a5f5d6e23978
jakaś klasa: https://drive.google.com/open?id=0B266UVYDsZPvZm1UYm9YQXFOTE0

[GotoFinal]

@afe1: android nic do tego nie ma, to musi tak działać, ciekawostką jest tu tylko zachowanie javac i eclipse