eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingjaki wybrac jezyk? › Re: jaki wybrac jezyk?
  • Data: 2011-08-17 06:11:58
    Temat: Re: jaki wybrac jezyk?
    Od: Michal Kleczek <k...@p...onet.pl> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    On 2011-08-16 22:27, Maciej Sobczak wrote:
    > On Aug 16, 8:27 am, Michal Kleczek<k...@p...onet.pl> wrote:
    >
    >> Dobre.
    >> Ale nieprawdziwe :)
    >
    > Sprawdziłeś?
    >
    >> Java rzuci ClassCastException na pierwszym add (fakt - w runtime).
    >
    > To ja mam zepsutą Javę (1.6.0), bo u mnie rzuca dopiero na drugim add.
    >
    >> 1. Wymaga tego specyfikacja TreeSet.add()
    >
    > Wg. dokumentacji (6) wyjątek leci "if the specified object cannot be
    > compared with the elements currently in this set ". Czyli jeśli zbiór
    > jest pusty, to ma nie lecieć.
    >
    >> 2. Zweryfikowalem zrodla
    >
    > W jakiej wersja Javy?

    1.7
    TreeMap:
    public V put(K key, V value) {
    Entry<K,V> t = root;
    if (t == null) {
    compare(key, key); // type (and possibly null) check
    ...
    }


    >
    >> ktorej put() w przypadku gdy mapa jest pusta probuje porownac klucz sam
    >> ze soba (wlasnie w celu zweryfikowania typu).
    >
    > I to ma być "statyczna kontrola typów"? Porównywanie obiektu samego ze
    > sobą w run-time?
    > Ale jaja. :-D
    >
    >> API _zawsze_ mozna spieprzyc
    >
    > To nie jest kwestia API. TreeSet<NonComparable> jest bez sensui w
    > poważnym języku można to sprawdzić *od razu*. Nawet bez dostępu do
    > implementacji klasy TreeSet.

    TreeSet<NonComparable> _nie_ jest bez sensu, bo mozna uzyc Comparatora
    zeby porownac elementy. Problem lezy w tym, ze Klasa TreeSet istniala
    przed wprowadzeniem generykow (i trzeba bylo zachowac konstruktory).

    Wyobraz sobie, ze TreeSet wyglada tak:
    public class TreeSet<T> {
    protected TreeSet() {...}
    protected TreeSet<Comparator<? super T>>() {...}

    public static <T extends Comparable> TreeSet<T> make() {...}
    public static <T> TreeSet<T> make(Comparator<? super T> comparator)
    {...}
    }

    (fakt, ze mogliby dolozyc do Javy jakas mozliwosc dodawania "type
    bounds" konstruktorom - byloby wygodniej)

    lub ew. po prostu dwie rozne klasy TreeSet jak pisalem wczesniej.

    Tyle, ze obydwie takie zmiany bylyby niekompatybilne z Java 1.4.

    > Tak, właśnie np. Ada nie potrzebuje widzieć implementacji, żeby
    > stwierdzić, że to jest bez sensu. I to jest właśnie statyczna kontrola
    > typów a nie jakieś machanie rękami w run-time.
    >

    Java tez nie potrzebuje. Pod warunkiem, ze tworca API biblioteki dobrze
    wykorzystal cechy jezyka. (Oczywiscie - Ada ma mocniejszy system typow,
    ale akurat w tym wypadku to nie ma to znaczenia).

    --
    Michal

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: