Повторюсь, заголовок несколько неудачный… для Java-гуру, коим я не являюсь, а для остальных, я считаю, ничего себе так.
И, вот к примеру, я знаю что в C++ что a[b], что b[a] эквиваленты для массивов, поскольку арифметика указателей. Однако я довольно плохо разбираюсь в ООП-тонкостях этого языка.
Гослинг говорил, что спонтанно придумал babe и ему просто понравилось. Но с тем же успехом и более подходяще по смыслу можно было придумать cafe feed. Так что, по-моему, вопрос открыт.
Вы ошиблись. У массива нет метода length(), зато есть поле length.
Откровенно говоря, мне трудно представить, где такое могло бы понадобиться. Ведь вычисления над литералом можно произвести и не в real-time.
Буду знать. Спасибо.
Вот, точно! Я в статье хотел и о тестировании ещё написать, но никак не мог вспомнить и найти источник. Но, на мой и не только мой взгляд, вовсе не для этого нужны классы в интерфейсах. По крайней мере не только для этого.
И согласитесь, Брюс не писал об истинном, ООП-применении их. И, хотя книга его замечательна, она не без недостатков. Примеры в ней, по-моему, оставляют желать лучшего. Собственно из них мало что понятно.
Не пытаясь возвысить себя, тем более над ним, замечу, что примеры я подбирал достаточно долго и тщательно. И если из них очевидны представляемые идиомы, значит я достиг своей цели.
Как бы там ни было, Java в отличие от C# обратно совместима начиная с версии 1.2. И, за некоторыми исключениями, write once, run anywhere, как и обещали. Что не скажешь о Шарпе с его постоянно появляющимися новыми и новыми версиями. Применимо ли к нему название DLL-hell?
Зря, по-моему, сановцы изменили нотацию версий. По сути Ява как была второй, так и осталась. Кардинальных изменений не было пока.
А можете указать главу и цитату про, пусть будет, второй пункт. Может я слишком плохо искал.
И где там упоминается зачем, собственно, нужны вложенные классы в интерфейсы?
Не спора ради.
В своё время говорили, что C# — лишь клон Java и призван отвлекать на себя её разработчиков. Теперь C# в части синтаксиса вырвался далеко вперёд. Но такая ситуация сложилась уже давно. Не потому ли Sun, чувствуя свою/Явы гибель раскрыла исходные коды?
Когда Oracle приобрела Sun, развитие языка сдвинулось с мёртвой точки. Глядишь в восьмой части реализуют весь обещанный «сахарок».
Я имел в виду использование break не по делу, то есть как в последнем примере. А по поводу return некоторые теоретики считают, что одна функция — один выход, с чем я, лично, не согласен.
Reflection не предназначен для рядового программирования. Это чёрный вход, нужный, к примеру, для инспектора объектов в IDE. Ничего с ним не поделаешь, и использовать его не по делу не нужно, только в особых случаях. Учитывая его, прямо сказать, кощунственные накладные расходы.
Да, безусловно. Жаль, что Google и Oracle «поссорились». Было бы намного лучше, если бы скооперировались, тем более, что Google, в Java вносит/вносил наибольший вклад (в сравнении с другими корпорациями).
Глядишь — и гугловские библиотеки стали бы частью стандарта.
К сожалению и, может, стыду документацией «Language specification» не зачитывался, я её как справочник обычно использую.
А вот по книгам «Effective Java» и «Thinking in Java» (всем рекомендую) я даже конспект составлял. Первым делом, перед тем как писать эту статью, я его перечитал и перелистал эти книжки. Пункт третий этой статьи, если не ошибаюсь, у Брюса Эккеля и почерпнул. Остальные пункты не из этих книг.
Выводы и примеры (за исключением одного) делал сам, исходя из своего понимания платформы Java. А заголовок действительно немного неудачный… для Java-гуру, коим я не являюсь (пока). Для всех же остальных, считаю, самое оно.
И, вот к примеру, я знаю что в C++ что a[b], что b[a] эквиваленты для массивов, поскольку арифметика указателей. Однако я довольно плохо разбираюсь в ООП-тонкостях этого языка.
Я специально написал про throw null, это была «дополнительная магия». Так тоже можно бросать исключения. Это скорее из разряда багов.
Откровенно говоря, мне трудно представить, где такое могло бы понадобиться. Ведь вычисления над литералом можно произвести и не в real-time.
Буду знать. Спасибо.
И согласитесь, Брюс не писал об истинном, ООП-применении их. И, хотя книга его замечательна, она не без недостатков. Примеры в ней, по-моему, оставляют желать лучшего. Собственно из них мало что понятно.
Не пытаясь возвысить себя, тем более над ним, замечу, что примеры я подбирал достаточно долго и тщательно. И если из них очевидны представляемые идиомы, значит я достиг своей цели.
Зря, по-моему, сановцы изменили нотацию версий. По сути Ява как была второй, так и осталась. Кардинальных изменений не было пока.
И где там упоминается зачем, собственно, нужны вложенные классы в интерфейсы?
Не спора ради.
Когда Oracle приобрела Sun, развитие языка сдвинулось с мёртвой точки. Глядишь в восьмой части реализуют весь обещанный «сахарок».
Глядишь — и гугловские библиотеки стали бы частью стандарта.
А вот по книгам «Effective Java» и «Thinking in Java» (всем рекомендую) я даже конспект составлял. Первым делом, перед тем как писать эту статью, я его перечитал и перелистал эти книжки. Пункт третий этой статьи, если не ошибаюсь, у Брюса Эккеля и почерпнул. Остальные пункты не из этих книг.
Выводы и примеры (за исключением одного) делал сам, исходя из своего понимания платформы Java. А заголовок действительно немного неудачный… для Java-гуру, коим я не являюсь (пока). Для всех же остальных, считаю, самое оно.