|
|
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
Добрый день! В связи с тем, что в java появились и универсальные типы, и assert'ы интересно- разработчики дальше Мейера прочитают? Чтобы ввести, например, контракты (require/ensure) или ещё что хорошего? Я уж не прошу r/o экспорт полей- всё одно толку мало с С-like синтаксисом :( -- Алексей Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 12:22:18 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
GKS_Samara Чтобы ввести, например, контракты (require/ensure) или ещё что хорошего? Что, простите, ввести? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 12:32:50 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
Почему бы не обратиться уже сразу к разработчикам? А они и объяснят, почему они хотят/не хотят это делать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 12:33:08 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
ррмяф пишет: >> Чтобы ввести, например, контракты (require/ensure) или ещё что хорошего? > Что, простите, ввести? Пример без этого: public double MySqrt(double value) { assert value >= 0; double result = ...; assert result >= 0; } Пример с этим: public double MySqrt(double value) require( value >= 0 ) ensure( result >= 0 ) { return ...; } Есть ещё инвариант- некое условие, которое должно выполнятся перед/после любого метода. Плюсы по сравнению с assert: 1. Можно отключать/включать каждую возможность директивами компилятора, в том числе для класса/пакета/библиотеки. 2. Требования автоматически попадают в документацию по классу (даже в ..class), даже если проверка была отключена. 3. ensure выполняется вне зависимости от точки выхода (return). А вообще Мейера почитать стоит :) -- Алексей Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 14:05:25 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
А разве для этого не подойдут аннотации? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 14:08:11 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
mysterio пишет: > А разве для этого не подойдут аннотации? Это про /** ... */ ? Они хуже, ибо: 1. Надо не забывать обновлять. 2. Можно забыться и добавить в наследнике более строгое условие. require на такое ругнётся- в перекрывающих методах можно только ослаблять предуслови (и только усиливать постусловие). Или я чего в java пропустил? -- Алексей Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 14:12:46 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
> > А разве для этого не подойдут аннотации? > Это про /** ... */ ? Да, загнался Но @ тоже не то- нет связи между декларированием ограниченя и его проверкой (если я правильно эту собаку понимаю). Ну и всё остальное в силе. -- Алексей Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 14:17:57 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
По форумам Sun витает призрак надежды что могут появится замыкания (closures). Никаких серьезных заявлений по поводу модификации языка ещё не встречал. Надо шерстить последние JSR ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 14:22:27 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
GKS_Samara Или я чего в java пропустил? Точно. Ты пропустил, что для java существуют препроцессоры с поддержкой пред/пост условий. Не знаешь, что такое аннотации и другие нововведения уже два года существующие в java 5. Ты ничего не читал о будущем java - java 6. И скорее всего мало писал руками в реальных проектах. Иначе молился бы не на пред/пост условия и ассерты (которые никто так и не стал использовать, несмотря на их "крутость"), а на метапрограммирование, вывод типов и функциональные типы, которые ощутимо сокращают количество строк кода, а так же на разработку через тестирование и любые другие формализации процесса разработки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 14:25:45 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
GKS_Samara Да, загнался Но @ тоже не то- нет связи между декларированием ограниченя и его проверкой (если я правильно эту собаку понимаю). Ну и всё остальное в силе. Курить это http://java.sun.com/j2se/1.5.0/docs/guide/apt/index.html. И не загоняться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 14:29:08 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
NotGonnaGetUs...Иначе молился бы не на пред/пост условия и ассерты (которые никто так и не стал использовать, несмотря на их "крутость")... +1 З.Ы. Вместо функционального типа можно использовать Method :) Но это медленно... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 14:31:38 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
NotGonnaGetUs GKS_Samara Да, загнался Но @ тоже не то- нет связи между декларированием ограниченя и его проверкой (если я правильно эту собаку понимаю). Ну и всё остальное в силе. Курить это http://java.sun.com/j2se/1.5.0/docs/guide/apt/index.html. И не загоняться. авторPage Not Found We are sorry, the page you have requested was not found on our system. Based upon the url that you requested, we would like to recommend pages that match your requested url. If you prefer, you may navigate through our site or use our search for your page. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 14:31:44 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
pamirPage Not Found Это задачка на смекалку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 14:32:31 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
NotGonnaGetUs pamirPage Not Found Это задачка на смекалку. аааа. Пошел решать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 14:35:29 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
я бы сказал, на внимательность ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 14:38:19 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
t!=i ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 14:52:07 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
NotGonnaGetUs пишет: > Точно. Ты пропустил, что для java существуют препроцессоры с поддержкой > пред/пост условий. Где существуют? > Иначе молился бы > не на пред/пост условия и ассерты (которые никто так и не стал > использовать, несмотря на их "крутость"), Ну дак их и нет в Жабе... > а на метапрограммирование, вывод типов и функциональные типы, > которые ощутимо сокращают количество строк кода, Где читать? > а так же на разработку через тестирование и любые другие > формализации процесса разработки. Но тут- то одно другому не мешает. Как раз пред/постусловия очень хорошо помогают разработке через тестирование. -- Алексей Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 15:38:56 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 15:51:15 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
BlazkowiczПо форумам Sun витает призрак надежды что могут появится замыкания (closures). Никаких серьезных заявлений по поводу модификации языка ещё не встречал. Надо шерстить последние JSR Замыкания уже реализуются вложенными классами - как ещё-то можно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 16:10:13 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
GKS_Samara Где существуют? В google. GKS_Samara Ну дак их и нет в Жабе... Ассертов нет? Предусловия нельзя писать? Всё есть если захотеть, но практически никто не пользуется. GKS_Samara Где читать? почитать Structure and Interpretation of Computer Programs и Concepts, Techniques, and Models of Computer Programming. почитать спецификацию на с# 3.0 c microsoft.com, посмотреть на сайте nemerle.org... Если очень интресно, то обратись на rsdn.ru в раздел декларативное программирование и философия. GKS_Samara Но тут- то одно другому не мешает. Как раз пред/постусловия очень хорошо помогают разработке через тестирование. Сколько серьёзных приложений с использованием пред/пост условий вы написали? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 16:18:16 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
BlazkowiczПо форумам Sun витает призрак надежды что могут появится замыкания (closures). Никаких серьезных заявлений по поводу модификации языка ещё не встречал. Надо шерстить последние JSR тынц ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 16:20:01 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
NotGonnaGetUs пишет: >> Где существуют? > В google. Это не ответ ;) > Ну дак их и нет в Жабе... > > Ассертов нет? > Предусловия нельзя писать? > Всё есть если захотеть, но практически никто не пользуется. Они там неудобны. Т.е. они не отражаются в документации автоматически. Это не совсем то. >> Где читать? > почитать Structure and Interpretation of Computer Programs > и Concepts, Techniques, and Models of Computer Programming. Это книги, или сайты? Интернет тормозной (вот даже пишу через nntp), сложно найти неизвестно что... > почитать спецификацию на с# 3.0 c microsoft.com, Оффтопик > посмотреть на сайте nemerle.org... Смотрю, спасибо. > Если очень интресно, то обратись на rsdn.ru в раздел декларативное > программирование и философия. Тоже почитаю. >> Но тут- то одно другому не мешает. >> Как раз пред/постусловия очень хорошо помогают разработке через >> тестирование. > Сколько серьёзных приложений с использованием пред/пост условий вы написали? Одно :) Не на eiffel, так что не очень удобно документировать. Но помогало быстро найти проблемы. -- Алексей Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 16:34:47 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
NotGonnaGetUs Ты ничего не читал о будущем java - java 6. конечно речь о java 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 16:38:02 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
GKS_Samara NotGonnaGetUs пишет: >> Где существуют? > В google. Это не ответ ;) Хоть я тебя и очень люблю, но в гугл за тебя лазить не буду. Наизусть ссылки не помню. GKS_Samara > Ну дак их и нет в Жабе... > > Ассертов нет? > Предусловия нельзя писать? > Всё есть если захотеть, но практически никто не пользуется. Они там неудобны. Т.е. они не отражаются в документации автоматически. Это не совсем то. О чём ты говоришь, если ты даже не удосужился познакомиться с имеющимися реализациями контрактного программирования для java? >> Где читать? > почитать Structure and Interpretation of Computer Programs > и Concepts, Techniques, and Models of Computer Programming. GKS_Samara Это книги, или сайты? Интернет тормозной (вот даже пишу через nntp), сложно найти неизвестно что... Широко известные книги, гугль тебе поможет. GKS_Samara > почитать спецификацию на с# 3.0 c microsoft.com, Оффтопик Это эйфель оффтопик :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 16:45:54 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
1. Мне-бы очень хотелось видеть беззнаковый тип данных. Надоело, знаете-ли форсировать 64 битные целые, там, где старая версия софта (бывш. С++) спокойно обходилась и 32 разрядами. С суммированием вектора байтов - тоже есть нюансы. 2. Не помешал-бы оператор "область видимости". Нечто вроде with в Паскале. (Не синоним import!) 3. Хотелось бы иметь возможность более детально управлять параметрами ссылок в куче Полезный эффект - оптимизация изпользования физ. памяти шаблонизированного ListArray, всевозможные hints сборщику мусора и т.п. 4. Более либеральный синтаксис "try-catch-finally". Пример: Java требует: Код: plaintext 1. 2. 3. 4. 5. Хотелось-бы записывать так: Код: plaintext 1. 2. 3. 5. Out-параметры в атомах. Код: plaintext 1. 2. 3. 4. 6. Классы-структуры. Могут быть полезны при разборе бинарных файлов. Должны иметь только финализированные свойства-атомы. Код: plaintext 1. 2. 3. 4. 7. Наличие препроцессора . Ну.. здесь вопрос очень сложен идеологически. Поэтому я готов слушать контраргументы. Не спешите упрекать меня в "левом" уклоне и причислять к лагерю M$-овцев. Большая половина этих предложений у меня возникла где-то в году эдак 97-98, когда я только начал осваивать Java. Сейчас - подвернулся удачный момент, чтобы их озвучить. C уважением Lord Mayton ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 20:25:55 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
mayton...написал... 1. Согласен. 2. Не согласен. Имхо он только читабельность кода затрудняет. Мое личное мнение, как человека, перешедшего на Яву после 4 лет работы чисто на Дельфе и 2 года проработавшего в режиме переключения между одной и второй. 3. А зачем нужен "второй С++"? С управлением ссылками и прочим? Ява, собственно, задумана как абстракция, позволяющая минимизировать управление памятью. 4. За такой "синтаксис" во многих местах отрывают разное . "Глушение" ошибок допустимо только на этапе отладки. Во всех продакшн-версиях они должны или отсылаться наверх по стеку, или обрабатываться. Делать один из грубейших приемов "плохого программирования" частью языка - бред. 5. Не согласен. Это нововведение противоречит всей концепции Явы как языка, имеющего в методах лишь одно возвращаемое значение. 6. "Разборка бинарников" - совсем не главная область применения, и вводить эту искуственную (по отношению к концепции) конструкцию для угоды 0,00..1% программистов - неправильно. 7. Да, действительно спорный вопрос. Я, например, категорически против. Да и разве аннотаций недостаточно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 21:14:04 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
Зашедший4. За такой "синтаксис" во многих местах отрывают разное . "Глушение" ошибок допустимо только на этапе отладки. Во всех продакшн-версиях они должны или отсылаться наверх по стеку, или обрабатываться. Делать один из грубейших приемов "плохого программирования" частью языка - бред. Мне кажется просто был плохой пример. Возможно хотелось что-то типа using из C#. Первый шаг - интерфейс Closable уже сделан. Зашедший6. "Разборка бинарников" - совсем не главная область применения, и вводить эту искуственную (по отношению к концепции) конструкцию для угоды 0,00..1% программистов - неправильно. Угу, дотнетчики к примеру тоже не понимают зачем они нужны. Зашедший7. Да, действительно спорный вопрос. Я, например, категорически против. Да и разве аннотаций недостаточно? Есть неплохие сторонние реализации включать эту фичу в core Java смысла действительно нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 21:50:09 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
Перспектив много: http://www.javalobby.org/java/forums/t84854.html http://cafe.elharo.com/java/ratjava/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 22:32:58 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
Зашедший 3. А зачем нужен "второй С++"? С управлением ссылками и прочим? Ява, собственно, задумана как абстракция, позволяющая минимизировать управление памятью. Я думал об этом. Однако оптимизация использвания кучи не дает мне покоя. Возможно, у меня сейчас не хватает аргументов. Однако, через некоторое время, если топик не заглохнет я приведу несколько доводов в пользу этого предложения. 4. За такой "синтаксис" во многих местах отрывают разное . "Глушение" ошибок допустимо только на этапе отладки. Во всех продакшн-версиях они должны или отсылаться наверх по стеку, или обрабатываться. Делать один из грубейших приемов "плохого программирования" частью языка - бред. Как вы будете поступать, если "наверх" ничего нельзя отослать? Т.е. метод базового интерфейса декларирован, как "не-throws" ? 5. Не согласен. Это нововведение противоречит всей концепции Явы как языка, имеющего в методах лишь одно возвращаемое значение. С такой "тягой" к концепциям, обсуждать перспективы довольно сложно, коллега. 6. "Разборка бинарников" - совсем не главная область применения, и вводить эту искуственную (по отношению к концепции) конструкцию для угоды 0,00..1% программистов - неправильно. Согласен. Выглядит несколько искусственно. Наверное я попал в этот крохотый процент программистов. Просто, если-бы у меня был выбор методик парсинга бинарных файлов, имеющих характерную структурность (заголовки, теги, таблицы), я бы выбрал наиболее лёгкий с точки зрения описания (декларация структуры атомов), и быстрый с позиций диска (блочные операции ввода вывода). Наверное меня поддержат программисты С++, которые аналогичные задачи выполняли довольно часто. 7. Да, действительно спорный вопрос. Я, например, категорически против. Да и разве аннотаций недостаточно? Ну.. может вы не будете так категоричны. Давайте подождем, что скажут по этому поводу другие мемберы. Большое спасибо за интерес к проблеме и за критику. С уважением Lord Mayton ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 22:44:13 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
maytonЯ думал об этом. Однако оптимизация использвания кучи не дает мне покоя. Возможно, у меня сейчас не хватает аргументов. Однако, через некоторое время, если топик не заглохнет я приведу несколько доводов в пользу этого предложения.Гондурас беспокоит? Говорят, если не думать об этом, помогает. Еще говорят весь мир пишет на жабе и не особо парится насчет уборщика мусора, а поди ж ты, есть люди, которым вечно все не так и не эдак. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 23:17:45 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 23:32:16 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
smbdy Код: plaintext Это не есть выход. Во первых я и так делаю проджекты на обоих языках. А во вторых мне не безразличена эволюция Java. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 23:39:19 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
Меня радует то, что в Java нет операций над указателями. И не нужны они ни в каком виде. При невозможности пустить ошибку вверх - нужно хотя бы логировать ошибку в файл и выдавать в результате функции ошибку. Хотя меня идеология thrown невероятно радует. Это просто щастье (после кое-каких других языков). Препроцессор, встроенный в язык - в первую очередь он снизит читабельность программ. А плюсы у него крайне сомнительные - для Java, разумеется. А вкусностей больше не хочется. Лишь бы работало стабильно и быстро. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2006, 00:22:48 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
[quot mayton]....[/quote] 1. Не знаю. У меня задач таких не стояло. Поэтому 0. :) 2. Использовал его в течение первух двух или трех лет писания на Delphi. В течение оставшихся 4(5) - может пару раз. Такие фишки как with x do with b do фиг разберешь. Плюс старые IDE (D3-D6) на этом деле подглючивали. 3. java.lang.ref 4. Будем считать, что вы ТАК не писали. Потому как если писали - двойка вам в области работы с исключениями. 5. Скорее нет, чем да. Рефакторинг "Замена данных объектом" или как-то так вам в помощь. 6. Плюс в очень редко используемой функциональности. Мне не сложно написать input.readbyte();. Эта фишка, как я понимаю, не вписывается в концепцию Java. Тут идет почти прямая работа с памятью. 7. Анатоции. Аспектно-ориентированное программирование. NetBeans (?). PS Не обижайтесь, но надо следить за новшествами языка, а не использовать его версию 97-98 года. Это я про 3 и 7. Ну а 4 - это нечто. ТАК ДЕЛАТЬ НЕЛЬЗЯ! Никогда. По меткой аналогии Блоха (?) - это тоже самое, что отключить пожарную сигнализацию, чтобы не мешала спать (по памяти и чуть поправлено). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2006, 01:49:54 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
[quot mayton Как вы будете поступать, если "наверх" ничего нельзя отослать? Т.е. метод базового интерфейса декларирован, как "не-throws" ? [/quot] Ну, я уже сказал про исключения. Вариантов много - кинуть assertion, кинуть не проверяемое исключение времени исполнения. Как минимум - вывод сообщения в протокол работы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2006, 01:53:55 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
mayton 1. Мне-бы очень хотелось видеть ... 5. Out-параметры в атомах. 6. Классы-структуры. 7. Наличие препроцессора . Ну.. здесь вопрос очень сложен идеологически. Поэтому я готов слушать контраргументы. Вместо out параметров и структур хочу кортежи. Для возвращаемых значений, ака Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Для паттерн матчинг, ака Код: plaintext 1. 2. 3. 4. 5. 6. а так же удобные методы для работы с листами, как это сделано во многих скриптовых и функциональных языках. Но в приницпе, всё это появится ввиде поддержки скриптовых языков в java 7. В том же groovy это почти есть :) А вместо препроцессора - макросы :) Смешной язык получился бы. Думаю после появления замыканий в 7 версии, появятся и остальные фичи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2006, 11:06:43 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
Leonidv[quot mayton]....[/quote] 3. java.lang.ref Я сначала понял, что mayton про некое подобие "арифметики указателей" говорил. Хотя если он имел в виду просто "слабые ссылки" этц - тогда это просто незнание языка :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2006, 14:14:43 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
Зашедший Хотя если он имел в виду просто "слабые ссылки" этц - тогда это просто незнание языка :) Очень на то похоже ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2006, 15:06:32 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
NotGonnaGetUsНо в приницпе, всё это появится ввиде поддержки скриптовых языков в java 7. В том же groovy это почти есть :) А вместо препроцессора - макросы :) Смешной язык получился бы. Думаю после появления замыканий в 7 версии, появятся и остальные фичи. Поддерживаю вас. Не могли-бы дать ссылочку на анонс возможностей семёрки? (Искать неохота) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2006, 15:36:34 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
например: http://javatech.info/node/151 Nai tiruvantel ar varyuvantel i Valar tieyanna nu vilya ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2006, 15:47:19 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
Не отказался бы от компилятора Nemerle в байткод. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2006, 16:05:14 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
hinotfнапример: http://javatech.info/node/151 У меня - ссылка не работает. Правый фрейм - пустой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2006, 16:31:18 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
процитирую: Компания Sun через своих инсайдеров продолжает делиться информацией о следующих выпусках настольной Java платформы, а именно – Java SE 7. Данный материал является логическим продолжением ранее опубликованной заметки. Ниже представлена сводка изменений и дополнений в к базовому API и неязыковой функциональности, которые планируются в данный момент. Естественно, что к предполагаемой дате выхода Java SE 7 (2008 год), многое может измениться. Развитие модульности JSR 277 JavaTM Module System – спецификация предусматривает разработку замены формату JAR, и будет включать в себя такие компоненты: новый формат поставки (т.н. Java Module), предназначенный для распространения Java кода, связанных с ним ресурсов и метаданных: поддержка версий: репозиторий для хранения модулей на пользовательской станции с поддержкой изолированного хранения пакетов разных версий: поддержка в загрузчиках классов и приложений поиска, загрузки и проверки целостности модулей: набор средств для работы с модулями и репозиторием. Поддержка других языков программирования JSR 192 Supporting Dynamically Typed Languages on the JavaTM Platform – спецификация предусматривает добавление к набору инструкций JVM инструкции invokedynamic, ответственную за вызов метода с неизвестными во время компиляции типом возвращаемого значения и типами параметров, что облегчит создание компиляторов для динамически типизируемых языков, таких как Ruby и Python. Добавление нескольких реализаций динамических языков – к 2008 году (времени выхода платформы), разработчики надеются на создание (адаптацию) нескольких реализаций динамических языков, таких как JRuby, Jython, Beanshell. Возможно, некоторые из них будут включены в базовую поставку. Swing JSR 295 Beans Binding – спецификация предусматривает создание API, ответственного за синхронизацию свойств разных JavaBeans, в том числе с разными типами (конверсия и валидация). JSR 296 Swing Application Framework – создание базового каркаса приложения на Swing, отвечающего за следующие, общие для всех настольных приложений вопросы: Выделение жизненного цикла приложения (фазы начальной загрузки и завершения работы); Поддержка локализации ресурсов. Также ресурсы могут быть специфичными для платформы или «марки» приложения; Хранение сессии пользователя между сеансами; Поддержка асинхронного выполнения действий с индикацией состояния. JSR 303 Bean Validation – универсальный API для валидации данных в программе. Информация для валидирования задается с помощью аннотаций или XML дескрипторов. Прочее JSR 220 Java Persistence Architecture – в Java SE 7 планируется включить разработанный группой экспертов по EJB persistence API, значительно облегчающий работу с реляционными БД из объектно-ориентированного кода. JSR 260 Javadoc Tag Technology Update – различные дополнения к JavaDoc, такие, как: Категоризация методов и полей по типу использования; Семантический индекс классов и пакетов; Отделение статических, фабричных и устаревших методов от обычных (ординарных); Выделение методов доступа к полям (getters и setters); Комбинирование и разделение информации в т.н. views; Внедрение примеров и общих вариантов использования. JSR 255 Java Management Extensions Specification, version 2.0 – эволюционное развитие JMX и JMX Remote API, направленное на облегчение использования и добавление новых полезных свойств. Раннее планировалось включить его в состав Java SE 6. Наиболее интересными изменениями являются: Использование generics в JMX API; Использование аннотаций для описания MBeans; Возможность мониторинга сложных типом (за счет использования generics); Поддержка каскадных (federated) серверов MBeans. JSR 262 Web Services Connector for JavaTM Management Extensions (JMXTM) Agents – позволяет организовать доступ к JXM API с помощью web services. JSR 203 More New I/O APIs for the JavaTM Platform (NIO 2) – расширения существующего java.nio API следующими функциями: Новый интерфейс для доступа к специфическим для файловой системы атрибутам и сервисный интерфейс для реализации подключаемых реализаций файловых систем; API для асинхронных операций над сокетами и файлами; Завершение реализации функциональности из JSR 51(поддержка связывания, настройки опций и multicast datagrams). Часть из вышеперечисленных спецификаций планировалась к включению в Java SE 5 и Java SE 6. Будем надеяться, что у команды, разрабатывающей 7-й релиз Java SE, хватит ресурсов для реализации всего заявленного качественно и в срок. Nai tiruvantel ar varyuvantel i Valar tieyanna nu vilya ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2006, 17:16:08 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
hinotf ...Выделение методов доступа к полям (getters и setters);... ...Новый интерфейс для доступа к специфическим для файловой системы атрибутам и сервисный интерфейс для реализации подключаемых реализаций файловых систем; API для асинхронных операций над сокетами и файлами;... Большое спасибо за экскурс. Про геттеры и сеттеры хотел упомянуть, да как-то забылось. Жду с нетерпением новостей. C уважением Lord Mayton ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2006, 13:46:05 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
Леонид! Извините, что сразу не ответил. Был занят. Leonidv Ну, я уже сказал про исключения. Вариантов много - кинуть assertion, кинуть не проверяемое исключение времени исполнения. Как минимум - вывод сообщения в протокол работы. Все эти варианты я использовал. Но на каком-то этапе они мне были не нужны, так как включались в код, который финализировал работу прикладной системы. Leonidov Плюс в очень редко используемой функциональности. Мне не сложно написать input.readbyte();. Эта фишка, как я понимаю, не вписывается в концепцию Java. Тут идет почти прямая работа с памятью. Я не считаю такое ограничение принципиальным. Косвенно - работа с памятью всё-же идет через механизмы блочных операций java.io или java.nio. Для полноценной работы с классами-структурами нехватает маленького связующего звена - маппинга фрагмета памяти в экземпляр объекта, содержимое которго от нас надежно скрыто за интерфейсом атомов (полей экземпляра). Это ограничение я считаю избыточным. И еще раз по поводу идеологии . В одном из топиков я это говорил - "если есть возможность сократить и упростить код - программист это сделает", не взирая ни на какие идеологические ценности. Практика ставит всё на свои места! Эту истину я усвоил, поработав несколько лет в секторе внедрения и поддержки ПО. На моих глазах академичные решения рушились и их место занимали простые, подобно АК-47 но провернные временем механизмы. Почему мой разработчкик-джавист Сергей провозился с парсингом графического файла целый месяц и отодвинул сроки сдачи проекта? Ответ прост! Он пытался адаптировать С++-овский код, который работал со структурами (struct) и битовыми полями (bitfields) к той среде, которая эти структуры НЕ ПОНИМАЛА! Более того, когда портирование было закончено, красивый некогда исходник УСЛОЖНИЛСЯ и УВЕЛИЛИЛСЯ в размерах в три раза! Это что? Плата за идеологию? Почему идеология вызывет у меня так много нареканий? Почему нельзя вернуть из функции unsigned long? Почему нельзя просто просуммировать байты? Почему коллекция ArrayList<myObject> жрет столько-же памяти, сколько и ArrayList<Object> ? Почему swing-приложение вызывает бесконечные жалобы пользователей на тормознутость GDI? Почему файловые блокировки реализованы не средствами ОС, а средствами платформы? И этот поток "почему" у меня - бесконечен! Скажу честно. 99% исходного программного кода на Java, которые я внедряю, НИКТО НИКОГДА НЕ УВИДИТ, кроме меня самого, моих коллег. Так-что МНЕ НЕКОМУ ПОКАЗАТЬ КРАСОТУ ИЛИ ИДЕОЛОГИЧЕСКУЮ ЦЕЛОСТОСТЬ РЕШЕНИЙ! У меня - другие цели. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2006, 01:47:58 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
У меня к вам тоже возник вопрос "Почему вы пишите на идеологической правильной, но такой неудобной Java" ;) Впрочем, он риторический. И еще. Не совсем понял. Если известна и хорошо описана структура файла, то написать код считывающий его - ну это работа не на месяц. Максимум неделя. Я как-то раз работал с библиотечкой, JPcap, явно написанной настоящим программистом на C. И понял, почему многие C-программисты терпеть не могу Java. Так что все о чем вы говорите, я могу понять. Только принимать не хочу :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2006, 15:24:34 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
mayton Почему нельзя вернуть из функции unsigned long? Почему нельзя просто просуммировать байты? Почему коллекция ArrayList<myObject> жрет столько-же памяти, сколько и ArrayList<Object> ? Почему swing-приложение вызывает бесконечные жалобы пользователей на тормознутость GDI? Почему файловые блокировки реализованы не средствами ОС, а средствами платформы? Не знаю, и причин особых не вижу. А что мешает? Лист, хранящий набор указателей , независимо от типов объектов, на которые указывают эти самые указатели, будет иметь один и тот же размер. По-моему очевидно. Потому что оно работает на всех ОС, и работает одинаково . См. предыдущую строку. Уважаемый Mayton, позвольте Вам напомнить, что Ява - не язык для написания драйверов, не язык для разбора огромных бинарников, не язык для создания операционных систем и еще много чего "не". Это язык, который изначально создавался для распределенных гетерогенных сетевых приложений, кроссплатформенности и мультимедии. Хочется "эффективности и скорости в разборе бинарников" - вэлком в ассемблер. А как по мне - если в Яву добавят по просьбам особо "умных" товарищей не-кроссплатформенные вещи типо разбора файлов в структуры и т.п., и при написании очередной софтины мне придется делать отдельные брэнчи под те 4-5 ОС, под которые она должна работать... честно говоря, рука сама потянется к пистолету. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2006, 16:05:20 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
LeonidvУ меня к вам тоже возник вопрос "Почему вы пишите на идеологической правильной, но такой неудобной Java" ;) Впрочем, он риторический. Да. Вопрос риторический. И я не хочу, чтобы вы меня причисляли к противникам Java. Да. От меня часто исходит критика. Это моё кредо. Но лучше-уж оценивать технологию со стороны, глазом инженера с двумя высшимы техническими, чем испытывать щенячий восторг и раболепие перед софтверным гигантом, посещая семинары, больше похожие на маркетинг-планы "пирамидальных сект", где тебя прорабатывают, как будушего партнера. И я на самом деле не в силах и не вправе убеждать вас в том, плоха Java или хороша. Просто хотелось, чтобы появилость сомнение , что как известно - является ключом к пониманию . Я-же в форуме взял на карандаш некоторые недостатки языка и платформы которые ИМХО следует устранить в новых версиях. Как видите, это вызвало бурную реакцию зашедших коллег по топику. Ну.. что-ж. Ничего. Пускай поволнуются. А мы подождём седьмого релиза. И еще. Не совсем понял. Если известна и хорошо описана структура файла, то написать код считывающий его - ну это работа не на месяц. Максимум неделя. По поводу файла. Расскажу. Спецификация его зародилась в недрах одного закрытого предприятия. В принципе её как таковой-не было. Были скупые инструкции по работе с древним софтом и несколько запутанных исходников на С++, которые мы добыли каким-то чудом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2006, 23:32:17 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
mayton Почему мой разработчкик-джавист Сергей провозился с парсингом графического файла целый месяц и отодвинул сроки сдачи проекта? Ответ прост! Он пытался адаптировать С++-овский код, который работал со структурами (struct) и битовыми полями (bitfields) к той среде, которая эти структуры НЕ ПОНИМАЛА! Более того, когда портирование было закончено, красивый некогда исходник УСЛОЖНИЛСЯ и УВЕЛИЛИЛСЯ в размерах в три раза! Это что? Плата за идеологию? Потому что нужно учиться пользоваться инструментом. Вот: http://proklondike.com/java_knudsen_2dgraphics.html хотя бы Почему идеология вызывет у меня так много нареканий? Пишите на C++, кто вас заставляет пользоваться неудобным инструментом?? "Партия и правительство"? Хочется "эффективности и скорости в разборе бинарников" - вэлком в ассемблер. А как по мне - если в Яву добавят по просьбам особо "умных" товарищей не-кроссплатформенные вещи типо разбора файлов в структуры и т.п., и при написании очередной софтины мне придется делать отдельные брэнчи под те 4-5 ОС, под которые она должна работать... честно говоря, рука сама потянется к пистолету.Имхо бояться нечего, ТАМ люди вменяемые, все "достоинства" C++ вкусили еще 10 лет назад. Наоборот, сейчас все движется в сторону функциональщины, и в жабу хотят всунуть все карринги, замыкания и проч. которыми и в других-то языках мало кто пользуется из-за сложности и жабе они дадут мало пользы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2006, 23:32:31 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
maytonИ я на самом деле не в силах и не вправе убеждать вас в том, плоха Java или хороша. Просто хотелось, чтобы появилость сомнение , что как известно - является ключом к пониманию . Для интереса, посмотрите как-нибудь структуру использования Явы - для чего и где она юзается. Я лично считаю, что для своего основного применения - создание интернет-приложений и аналога "скриптового языка" (см. использование в Оракле, например) - это лучший инструмент по сочетанию мощности, гибкости и скорости. Большинство же предлагаемых Вами фич - поклоны в сторону работы с бинарниками, всяких синтаксических анализаторов и т.п. С моей точки зрения - очень похоже на требования прикрутить ручку к микроскопу, потому что им гвозди забивать неудобно. А не лучше ли использовать для забивания гвоздей молоток, а? А микроскоп для того, для чего он придуман? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2006, 14:23:57 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
abcdcdcdВот: http://proklondike.com/java_knudsen_2dgraphics.html хотя бы Смотрел ссылку. Боюсь что это мне не поможет т.к. не решает принципиально проблему чтения битовых полей. А поддержка стандартных файловых форматов мне не нужна т.к. я уже упоминал, что спецификация файла создавалась в рамках одной организации, и не была открыта для общего пользования. Но в любом случае, спасибо за участие ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2006, 16:56:01 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
mayton 6. Классы-структуры. Могут быть полезны при разборе бинарных файлов. Должны иметь только финализированные свойства-атомы. Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2006, 21:56:26 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
mayton 1. Мне-бы bla-bla... .... 7 . .. 8. Comparable-switch . Приведу просто пример. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 9. Перегузка операций... . (CPP - боян, а что делать! Жить-то надо...) ... Код: plaintext 1. 2. 3. 4. Сорри, за UP. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2006, 19:29:25 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
Не нужна Jav'е перегрузка. Comparable-switch - не так часто требуется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2006, 19:32:41 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
mayton 9. Перегузка операций... . (CPP - боян, а что делать! Жить-то надо...) ... Код: plaintext 1. 2. 3. 4. Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2006, 20:07:14 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
Leonidv Вопрос - вы видите в исходниках такой код. Что делается? Бессмысленно задавать такой вопрос сиплюсплюсникам. У них моск давно работает по-извращенчески, уж простите :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2006, 20:30:08 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
LeonidvВопрос - вы видите в исходниках такой код. Что делается? (кивает головой) Понимаю вашу иронию, Леонидов. А вас не удивляет возможность "СУММИРОВАТЬ" символьные последовательности (String) ? Что? Скажете .. дескать исключение из правил? Ну .. что-ж. Строить концепцию на исключениях - практика обнадёживающая ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2006, 20:58:33 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
maytonТак мож того? Паскакаль какой выбрать или Object Delphi? Или CPP? И не париться. Зачем жабой-то себя насиловать, тем более всякое г.. в неё тянуть - она в такое же г... и превратится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2006, 21:03:32 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
mayton (кивает головой) Понимаю вашу иронию, Леонидов. А вас не удивляет возможность "СУММИРОВАТЬ" символьные последовательности (String) ? Что? Скажете .. дескать исключение из правил? Ну .. что-ж. Строить концепцию на исключениях - практика обнадёживающая Простите, что влез. Строки - это вообще одно большое исключение в Java. И слава богу. Что оно такое одно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2006, 23:24:10 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
Donald KnuthТак мож того? Паскакаль какой выбрать или Object Delphi? Или CPP? И не париться. Зачем жабой-то себя насиловать, тем более всякое г.. в неё тянуть - она в такое же г... и превратится. Ты Паскаль не трожь. Нет там перегрузки и CS. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2006, 23:25:32 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
mayton Скажете .. дескать исключение из правил? Скажу, что для строк это уже давно правило ПМСМ - в Java есть исключения, для удобства. Те же самые примитивные типы. В чистом ООП им не место. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 00:21:06 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
maytonПонимаю вашу иронию, Леонидов. А вас не удивляет возможность "СУММИРОВАТЬ" символьные последовательности (String) ? Что? Скажете .. дескать исключение из правил? Ну .. что-ж. Строить концепцию на исключениях - практика обнадёживающая И вообще. Сейчас люди серьезные вещи обсуждают , а вы хотите на 10 лет назад все вернуть ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 00:49:56 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
Leonidv wrote: > *9. Перегузка операций...*. (CPP - боян, а что делать! Жить-то надо...) ... > public class complex{ > public complex operator+(complex arg){ bla-bla... }; > } > Bitmap bmp1 = *new* Bitmap(fileName1); > Bitmap bmp2 = *new* Bitmap(fileName2); > Bitmap bmp3 = bmp1+bmp2; > > Вопрос - вы видите в исходниках такой код. Что делается? Тривиально - Bitmap bmp3 = bmp1.operator+( bmp2 ); Операции- всего лишь синтаксические конструкции, не более. Другое дело, что криворукий автор может написать код, меняющий состояние bmp1. Это лечить сложно, но можно- ввести "чистые функции", которым запрещено менять состояние объекта и разрешить как операции только чистые функции :) -- Алексей Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 10:26:52 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
GKS_Samara Тривиально - Bitmap bmp3 = bmp1.operator+( bmp2 ); Операции- всего лишь синтаксические конструкции, не более. Ага. И (вспомнив анекдоты про equals): Код: plaintext 1. 2. 3. 4. И приоритеты: Код: plaintext 1. 2. И NPE (если будет разрешена не только статическая перегрузка операторов) : Код: plaintext 1. 2. 3. 4. 5. Одна тривиальность. GKS_Samara Это лечить сложно, но можно- ввести "чистые функции", которым запрещено менять состояние объекта и разрешить как операции только чистые функции :) Любишь XSLT? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 11:10:23 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
петяя Любишь XSLT? :) не трошшшшьььь святое!!!!!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 11:16:13 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
петяя wrote: > И (вспомнив анекдоты про equals): > A a; > B b; > > a + b == b + a? Нет, но сделать a+b.equal(b+a) - это уж забота программиста :) Хотя, возможно, лучше так: public (static-неявно) operator+(Complex a, Complex b) - это ближе к операциям. > И приоритеты: > > bmp1 + bmp2 * bmp3 == bmp1.operator+(bmp2.operator*(bmp3)) ? > bmp1 + bmp2 * bmp3 == (bmp1.operator+(bmp2)).operator*(bmp3) ? Первое, по логике. > И NPE (если будет разрешена не только статическая перегрузка операторов) : > A a = *null*; > B b = *new* B(); > > (a + b) -> NPE? > (b + a) -> No NPE? > Одна тривиальность. Да, это непросто, равно как и смешение типов. Лучше статическая типизация. PS: вообще непонятно, почему можно делать int a = b+c, но нельзя Integer a = b+c? Ясно, что подумать придётся, но думать полезно :) -- Алексей Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 11:39:14 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
GKS_Samara PS: вообще непонятно, почему можно делать int a = b+c, но нельзя Integer a = b+c? Ясно, что подумать придётся, но думать полезно :) -- Алексей Posted via ActualForum NNTP Server 1.3 Кто сказал, что нельзя? 5-я Java использует для этого автоматическое преобразование типов. Что мне тоже оччень не нравится :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 11:44:27 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
GKS_Samara Кто сказал, что нельзя? 5-я Java использует для этого автоматическое преобразование типов. Что мне тоже оччень не нравится :( Ага. На мой взгляд совершенно бесполезное нововведение, которое только мешает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 12:39:45 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
GKS_Samara > a + b == b + a? Нет, но сделать a+b.equal(b+a) - это уж забота программиста :) Любишь создавать себе дополнительные заботы? Тогда понятно зачем тебе нужна перегрузка операторов. GKS_Samara Хотя, возможно, лучше так: public (static-неявно) operator+(Complex a, Complex b) - это ближе к операциям. Статическая перегрузка наследование - две вещи не совместимые. Попробуй описать класс Complex<T> с перегрузкой операции сложения, где T - тип реальной/мнимой частей. Особое внимание на случаи Complex<Integer> и Сomplex<Complex<Integer>>. GKS_Samara > И приоритеты: > > bmp1 + bmp2 * bmp3 == bmp1.operator+(bmp2.operator*(bmp3)) ? > bmp1 + bmp2 * bmp3 == (bmp1.operator+(bmp2)).operator*(bmp3) ? Первое, по логике. По чьей логике? В java вызов методов идёт с лева на право, поэтому логичен именно второй вариант. Или хочешь, чтобы компилятор менял очередность вызовов методов в зависимости от их имён?! GKS_Samara > (a + b) -> NPE? > (b + a) -> No NPE? > Одна тривиальность. Да, это непросто, равно как и смешение типов. Лучше статическая типизация. Чем лучше-то и какое смешение? Полиморфизм уже стал злом? :) GKS_Samara PS: вообще непонятно, почему можно делать int a = b+c, но нельзя Integer a = b+c? Всё понятно: int простой тип, а Integer - объект. GKS_Samara Ясно, что подумать придётся, но думать полезно :) Если бы работодателю хотелось чтобы ты думал, а не писал работающий код, то ты писал бы программы на с++. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 15:23:55 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
leafoxАга. На мой взгляд совершенно бесполезное нововведение, которое только мешает. Integer i = 5; лучше, чем Integer i = new Integer(5); Обоснование: нужно набирать больше буковок. А чем обуславливается ваше критическое отношение к данному нововведению? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 15:26:20 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
петяя Integer i = 5; лучше, чем Integer i = new Integer(5); Обоснование: нужно набирать больше буковок. А чем обуславливается ваше критическое отношение к данному нововведению? Ничем не лучше. Это ботва, которая начинает со временем путать. С объектами нужно работать как с объектами, а с примитивными типами - как с примитивными типами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 15:28:08 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
(меня всё равно забанятЭто ботва, которая начинает со временем путать. Глупость. Со временем к фичам языка только больше привыкаешь. (меня всё равно забанят С объектами нужно работать как с объектами, а с примитивными типами - как с примитивными типами. Это приводит к дублированию кода универсальных алгоритмов/методов, которого можно было бы избежать в некоторых случаях (не критичных к производительности). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 15:34:32 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
петяя Это приводит к дублированию кода универсальных алгоритмов/методов, которого можно было бы избежать в некоторых случаях (не критичных к производительности). У вас часто такие "универсальные" алгоритмы/методы встречаются? Приведите, пожалуйста, пример. Из жизни, а не из области сферических коней. В вакууме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 15:47:27 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
(меня всё равно забанят) С объектами нужно работать как с объектами, а с примитивными типами - как с примитивными типами. Как вы собираетесь работать с экземпляром Integer, как с объектом? практического смысла как раз не видно. Методами состояние не меняется ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 16:16:47 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
LINUXER Как вы собираетесь работать с экземпляром Integer, как с объектом? практического смысла как раз не видно. Методами состояние не меняется Лично я Integer'ы (а скорее Double) использую в бинах (для Struts). И еще для передачи значений между EJB. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 16:31:30 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
(меня всё равно забанят) Лично я Integer'ы (а скорее Double) использую в бинах (для Struts). И еще для передачи значений между EJB. И чем же автоупаковка может запутать? Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 16:49:23 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
LINUXER И чем же автоупаковка может запутать? Да хотя бы вот этим: Код: plaintext 1. 2. 3. 4. 5. Результат: i1 >= i2: true i1 <= i2: true i1 == i2: false ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 17:04:22 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
leafox LINUXER И чем же автоупаковка может запутать? Да хотя бы вот этим: Код: plaintext 1. 2. 3. 4. 5. Результат: i1 >= i2: true i1 <= i2: true i1 == i2: false Чем здесь можно запутать-то? це ж объекты. хотя б так мозги попудрить :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 17:16:00 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 17:23:02 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
Timm leafox LINUXER И чем же автоупаковка может запутать? Да хотя бы вот этим: Код: plaintext 1. 2. 3. 4. 5. Результат: i1 >= i2: true i1 <= i2: true i1 == i2: false Чем здесь можно запутать-то? це ж объекты. хотя б так мозги попудрить :) Если это объекты, тогда как работает вот это: System.out.println("i1 >= i2: " + (i1>=i2) );? Я бы не смог применить операцию >= к ссылкам. А все оттого, что сработал механизм autoboxing. Получается, что в первых двух случаях сравнение происходило по значению, а в третьем - по ссылке. Путаница. Нужно быть более чутким, оперируя оболочечными типами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 17:47:49 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
LINUXER Код: plaintext 1. 2. 3. 4. 5. Вас путает строка? Вам непривычно, что их можно складывать? Тяжелое наследие C? :) Слава богу, что разработчики Java сделали такие исключение для строк, что с ними не нужно извращаться. Меня лично не путает. Это исключение - одно единственное. Причем работает всё это совешенно логично и удобно. А вот автобоксинг - не нужен. Не то что ни разу не пригодился, а наоборот, потом пришлось скомпилить под 1.4 и вычищать неявные преобразования (которые я делал просто не невнимательности, вместо long писал Long). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 17:56:37 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
leafox LINUXER И чем же автоупаковка может запутать? Да хотя бы вот этим: Код: plaintext 1. 2. 3. 4. 5. Результат: i1 >= i2: true i1 <= i2: true i1 == i2: false Offtop. Спасибо, буду знать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2006, 18:09:49 |
|
||
|
|

start [/forum/topic.php?all=1&fid=59&tid=2147162]: |
0ms |
get settings: |
23ms |
get forum list: |
21ms |
check forum access: |
7ms |
check topic access: |
7ms |
track hit: |
82ms |
get topic data: |
19ms |
get forum data: |
4ms |
get page messages: |
156ms |
get tp. blocked users: |
3ms |
| others: | 304ms |
| total: | 626ms |

| 0 / 0 |
