[biblioteka] Rounder, Czyli jak round() wywołało frustrację Opcje

[greycoffey]

Hej,

sfrustrowany dzisiaj zachowaniem funkcji round() której zaokrąglanie half up i half down nie jest tym, za co się podaje, spłodziłem klasę, która robi to poprawnie. Zawiera interfejs oraz domyślną implementację zaokrąglacza, druga implementacja (oparta na bcmath) właśnie się tworzy (co do tego, macie jakiś pomysł na implementację metod roundHalfEven() i roundHalfOdd() w Pamil\Rounder\BcmathRounder w gałęzi bcmath-support?).

Przykład użycia i kod na GitHubie.

[Crozin]

Naprawdę wątpię, żeby komuś chciało się do zaokrąglania liczb szukać biblioteki.

Skąd wiesz czy komuś będzie się chciało wpisać w Googlea php number rounding library?

Z całym szacunkiem do włożonego trudu (w pisanie klasy i implementacji / testów jednostkowych nie zdzierżę bo nie cierpię nadgorliwości).

Obecność testów jest dla wielu osób/projektów wręcz wymogiem przy decydowaniu się na skorzystanie z kodu osób trzecich.

Pamiętaj, że nie każdy ma takie potrzeby jak Ty.

@crozin Przeczytaj sobie mój artykuł, o którym pisałem w jednym z moich poprzednich postów i przemyśl sobie to szybko dojdziesz do wniosku, że interfejsy mogą stać się problemem jeśli się ich używa "zamiast" po prostu dziedziczenia.

Chodzi Ci o artykuł Abuse of interfaces in Java? Przeczytałem go od razu i nie zgadzam się z częścią tez w nim zawartych. Nie wiem też w czym interfejsy same w sobie miałby utrudniać dziedziczenie (pomijaj też fakt, że ich wykorzystanie umożliwia w ogóle skorzystanie z dziedziczenia w wielu przypadkach w przeciwieństwie do klas abstrakcyjnych). Mam wrażenie jakbyś podchodził do tematu na zasadzie interfejsy kontra dziedziczenie/klasy abstrakcyjnie, zamiast normalnie, tj. interfejsy plus dziedziczenie/klasy abstrakcyjne.