Комментарии 133
Clojure, Groovy, JRuby, и Scala — за ними будущее (по крайней мере неделёкое).
Разум когда-нибудь победит.
Разум когда-нибудь победит.
Вы знаете, может быть когда-нибудь и победит, но когда посмотришь что произошло с LISP и SmallTalk — которые я считаю революционными, то недалекое будущее вызывает улыбку… :-) Но поживем увидим.
Главное надо перестать обманывать себя и других называя старое новым. Ведь никакое это не новое и тем более не поколение, это просто java.next символизирующее лишь следующую версию java, которая пытается catch up с другими языками, но никак не с «поколением» и тем более не с «будущим» (если оно конечно подразумевается).
Они все развивались на фоне одного и того же языка: Java. На их дизайн постоянно влияло изучение того, что работает хорошо в Java, а что нет.
Странно, а мне всегда виделось что именно Джава развивалась на фоне всех других языков а не наоборот. Сперва это был SmallTalk с синтаксисом от C, потом они коллекции перетащили, затем шаблоны… А тут бац — все местами поменяли, яйцо курицей сделали. Вот уж эти Java-исты :-) Все у них вокруг Java крутится.
Ну в целом примерно так.
Главное надо перестать обманывать себя и других называя старое новым. Ведь никакое это не новое и тем более не поколение, это просто java.next символизирующее лишь следующую версию java, которая пытается catch up с другими языками, но никак не с «поколением» и тем более не с «будущим» (если оно конечно подразумевается).
Они все развивались на фоне одного и того же языка: Java. На их дизайн постоянно влияло изучение того, что работает хорошо в Java, а что нет.
Странно, а мне всегда виделось что именно Джава развивалась на фоне всех других языков а не наоборот. Сперва это был SmallTalk с синтаксисом от C, потом они коллекции перетащили, затем шаблоны… А тут бац — все местами поменяли, яйцо курицей сделали. Вот уж эти Java-исты :-) Все у них вокруг Java крутится.
Ну в целом примерно так.
все эти 4 языка нишевы и не верю что имеют какие-либо шансы добиться успеха. Все они завязаны на платформу Java и без её дальшего продвижения не имеют смысла. А с разширением Java как раз проблемы я считаю рынок достиг насыщения. Java уже больше не решает проблем она их больше создаёт. Где-то прочитал «Java — это кобол современности» и я с этим согласен. Зачем использовать три-четыре слоя абстракции и плодить лишние сущности?
Ваши-то предложения какие?
Все на Лисп! :-D
Моё дело маленькое я выбираю то что мне ближе и приемлимо для заказчика.
С Groovy и им подобным Sun вскакивает в поезд который уже ушол.
За последние годы я не вижу разширения сферы применения Java, более того она понемногу я бы сказал теряет занятые ниши. Десктоп — здесь она никогда ничего толком не занимала, мобильные решения — Java ME больше в дешёвых устройствах, в более сложных альтернативные решения, веб — PHP, Perl, Python, Ruby взрастили новую генерацию разработчиков которые виросли с маленьких проэктов и уже реализируют на этих платформах большие. Более того пока это не стало масовым явлением но с Java уже уходят разработчики. Я не знаю людей которые переходят с Ruby, Python на Java, но обратное случается. С Java происходит то же что и с C++ когда-то это больше не круто, это скучно, творческая моодёжь ищет способы для выражения в других местах. Да вы скажете Java это огромная индустрия с милиардными оборотами, вы правы, но я уверен что с Java происходит то же что и с COM в своё время, только агония будет намного дольше потому что значительно больше ресурсов угрохано.
С Groovy и им подобным Sun вскакивает в поезд который уже ушол.
За последние годы я не вижу разширения сферы применения Java, более того она понемногу я бы сказал теряет занятые ниши. Десктоп — здесь она никогда ничего толком не занимала, мобильные решения — Java ME больше в дешёвых устройствах, в более сложных альтернативные решения, веб — PHP, Perl, Python, Ruby взрастили новую генерацию разработчиков которые виросли с маленьких проэктов и уже реализируют на этих платформах большие. Более того пока это не стало масовым явлением но с Java уже уходят разработчики. Я не знаю людей которые переходят с Ruby, Python на Java, но обратное случается. С Java происходит то же что и с C++ когда-то это больше не круто, это скучно, творческая моодёжь ищет способы для выражения в других местах. Да вы скажете Java это огромная индустрия с милиардными оборотами, вы правы, но я уверен что с Java происходит то же что и с COM в своё время, только агония будет намного дольше потому что значительно больше ресурсов угрохано.
Судя по западным блогам, есть таки люди, которые переползают с Ruby на Groovy. А это уже Java-платформа. Кроме того, я не стал бы цепляться за «угрохано больше ресурсов». Java предоставляет реальные преимущества в виде мультиплатформенности, неплохого быстродействия, прорвы разнообразных библиотек и множества разработчиков.
1. Sun не занимается продвижением Groovy, а над JRuby/Jython работает всего 3 человека и их основная цель — сделать Java привлекательной платформой для деплоймента решений на этих языках. Эти языки — скриптовые и Sun не видит в них Java-заменителя.
2. Десктоп — IDE и корпоративные приложения. Тут недавно писали про БАК — так вот системы для его управления тоже написаны на Java.
3. Под J2ME на данный момент работают практически все устройства за исключением iPhone. Google Android тоже строится вокруг Java.
4. Я не понимаю как язык может вырастить «генерацию разработчиков». Вот вам рынок вакансий:
За последние 3 года не было как резкого роста динамических языков, так и падения популярности Java.
5. По поводу перехода. Twitter переписывает свою серверную часть на Java платформе с помощью Java/Scala. Один из крупных продуктов переехал с Python/Zope на J2EE — Nuxeo.
6. «Скучно» — это не показатель. Java — основной язык в университетах. Java — основная платформа крупнейших вендоров middleware: IBM, Oracle, Red Hat, SAP. Те, кто считают, что языки выращивают поколения разработчиков — могут себе повесить табличку «You are not the fucking industry!». Java работает в банках, на биржах и на данный момент кроме С#.NET у неё нет альтернатив.
7. Чтобы переходить с Java на что-то другое — должны быть определённые причины. Вы пока ни одной веской не назвали. Если какой переход и будет — то динамических языков на платформу Java: JRuby уже является хорошей альтернативой: вопрос совместимости уже решён, а вопрос скорости решается быстрыми темпами.
Вообщем никакой альтернативный _платформы_ вы так и не назвали, и вообще по-видимому смутно представляете себе то, о чём говорите.
2. Десктоп — IDE и корпоративные приложения. Тут недавно писали про БАК — так вот системы для его управления тоже написаны на Java.
3. Под J2ME на данный момент работают практически все устройства за исключением iPhone. Google Android тоже строится вокруг Java.
4. Я не понимаю как язык может вырастить «генерацию разработчиков». Вот вам рынок вакансий:
За последние 3 года не было как резкого роста динамических языков, так и падения популярности Java.
5. По поводу перехода. Twitter переписывает свою серверную часть на Java платформе с помощью Java/Scala. Один из крупных продуктов переехал с Python/Zope на J2EE — Nuxeo.
6. «Скучно» — это не показатель. Java — основной язык в университетах. Java — основная платформа крупнейших вендоров middleware: IBM, Oracle, Red Hat, SAP. Те, кто считают, что языки выращивают поколения разработчиков — могут себе повесить табличку «You are not the fucking industry!». Java работает в банках, на биржах и на данный момент кроме С#.NET у неё нет альтернатив.
7. Чтобы переходить с Java на что-то другое — должны быть определённые причины. Вы пока ни одной веской не назвали. Если какой переход и будет — то динамических языков на платформу Java: JRuby уже является хорошей альтернативой: вопрос совместимости уже решён, а вопрос скорости решается быстрыми темпами.
Вообщем никакой альтернативный _платформы_ вы так и не назвали, и вообще по-видимому смутно представляете себе то, о чём говорите.
Ну а насколько быстро все это дело войдет в широкие массы? Вот в чем вопрос.
А кто мешает? По крайней мере для скриптов и небольших собственных проектов эти языки каждый может использовать хоть сейчас. Начните с себя!
Для скриптов и небольших собственных проэктов можно использовать Python, Perl, Haskell, ErLang например. А тянуть монстрика в виде Java только чтобы запустить скрипт который периодически почитит TEMP увольте, мне для этого bat-ника хватит.
а что для вас есть критерий «монстрообразности»?
Критерий монстрообразности для того чтобы возвратить пользовтелю персонализированую страничку с надписью Привет Джо, запустить виртуальную машину, в которой будут подгружены все эти JEE, Struts, Hibernate и ещё над всем этим запустить интерпритатор скриптового языка, а апофигеем всего этого, запустть это всё на виртуальной машине которая хостится на кластера 200-ядерного сервера.
Я считаю что Java и в меньшей мере .NET (но он семимильными шагами движется по стопам Java) превысили все мыслимые и немыслимые пределы по сложности, когда даже для вникания в одну библиотеку нужно очень много времени. Эта сложность больше не помагает, больше того она уже почти гарантировано ухудшает конечный результат, но при этом так же гарантировано даёт средний результат и уменьшает риск полного провала (что для большинства является достаточным доводом для использования).
Примеры построения самых сложных и самых нагруженных систем(google например) показывают что ни Java ни .NET ни в коем случае не могут быть использованы в качестве основного компонента, наоборот пытаются использовать что-то максимально легковесное и простое.
Я считаю что Java и в меньшей мере .NET (но он семимильными шагами движется по стопам Java) превысили все мыслимые и немыслимые пределы по сложности, когда даже для вникания в одну библиотеку нужно очень много времени. Эта сложность больше не помагает, больше того она уже почти гарантировано ухудшает конечный результат, но при этом так же гарантировано даёт средний результат и уменьшает риск полного провала (что для большинства является достаточным доводом для использования).
Примеры построения самых сложных и самых нагруженных систем(google например) показывают что ни Java ни .NET ни в коем случае не могут быть использованы в качестве основного компонента, наоборот пытаются использовать что-то максимально легковесное и простое.
ээ, стоп-стоп-стоп. для того чтобы «чтобы запустить скрипт который периодически почитит TEMP» не нужно никаких j2ee, это раз.
для написания простого вебприложения на grails достаточно прочесть одну небольшую книжку и всё. Для «привет джо» достаточно (вы не поверите!)
groovy -l 5000 -e «
println 'HTTP/1.0 200 OK\n'
println 'Привет, Джо!'
return 'success'
»
а в этом топике вообще речь и идёт об упрощении как раз.
для написания простого вебприложения на grails достаточно прочесть одну небольшую книжку и всё. Для «привет джо» достаточно (вы не поверите!)
groovy -l 5000 -e «
println 'HTTP/1.0 200 OK\n'
println 'Привет, Джо!'
return 'success'
»
а в этом топике вообще речь и идёт об упрощении как раз.
хорошо дя того чтобы очистить temp мне достаточно всего одной-двох команд:
Например что-то похожее на это
at 10:00 «del /F /S /Q %TEMP%\*.*»
И мне не нужна виртуальная машина Java, не нужен .NET Framework и последний апдейт IE.
Об упрощениях. Всё переставляя с ног на голову упрощения не добъёшся.
Вводя ещё один уровень косвености мы просто спрятали сложность системы но упрощения не добились, более того мы создали ещё одну точку отказа и в его поисках придётся пройти всю цепочку. Я могу отрицать что Сонце взойдёт на востоке, но факты таковы что утром сонце встанет на востоке, а принцыпы «Бритвы О́ккама» сформулированы ещё 600 лет назад и доказаны долгим опытом проб и ошибок.
Если можно сделать проще то нужно делать проще иначе жизнь снабдит тебя сильным подзатыльником.
Например что-то похожее на это
at 10:00 «del /F /S /Q %TEMP%\*.*»
И мне не нужна виртуальная машина Java, не нужен .NET Framework и последний апдейт IE.
Об упрощениях. Всё переставляя с ног на голову упрощения не добъёшся.
Вводя ещё один уровень косвености мы просто спрятали сложность системы но упрощения не добились, более того мы создали ещё одну точку отказа и в его поисках придётся пройти всю цепочку. Я могу отрицать что Сонце взойдёт на востоке, но факты таковы что утром сонце встанет на востоке, а принцыпы «Бритвы О́ккама» сформулированы ещё 600 лет назад и доказаны долгим опытом проб и ошибок.
Если можно сделать проще то нужно делать проще иначе жизнь снабдит тебя сильным подзатыльником.
никто ж не спорит, что очистить temp можно и без groovy. Однако чуть более сложные задачи на груви уже, возможно, будет решать проще, чем батфайлом. Однако ж речь не об этом…
про упрощение:
а зачем же тогда был придуман си, си++, java etc? Это ж ведь лишняя точка отказа, давайте писать на машинных кодах! я, конечо, преувеличиваю, но и вы неправы.
про тяжеловесность виртуальной машины:
запуск даже groovy-скрита через groovy -e происходит меньше, чем за секунду
про упрощение:
а зачем же тогда был придуман си, си++, java etc? Это ж ведь лишняя точка отказа, давайте писать на машинных кодах! я, конечо, преувеличиваю, но и вы неправы.
про тяжеловесность виртуальной машины:
запуск даже groovy-скрита через groovy -e происходит меньше, чем за секунду
Если я захочу писать скрипт то я возьм тот же CPython и скорость будет в разы больше Groovy. Groovy это интерпритатор в интерпритаторе.
Groovy, JRuby да и тот же JPython который существенно старее — это как раз попытки на основе одной «серебряной пули» — Java создать решения для ещё одной области и ещё немного продолжить существование платформы Java как таковой. Но это решение чрезвычайно избыточное и только сейчас многие програмисты на Java «открывают» благодаря Groovy, Scala для себя вещи которые в реальности существуют давно. Но только вот польза от этих обёрток и интерпретаций сомнительна, зачем пользоватся пересказом если есть возможность работать с оригиналом. В Groovy я не вижу никаких новых идей для того чтобы туда пришли люди с другим опытом, да Java-сты будут использовать потому что они были лишены этих возможностей, но остальным это не интересно и Java остаётся замкнутым на себя сообществом.
Groovy, JRuby да и тот же JPython который существенно старее — это как раз попытки на основе одной «серебряной пули» — Java создать решения для ещё одной области и ещё немного продолжить существование платформы Java как таковой. Но это решение чрезвычайно избыточное и только сейчас многие програмисты на Java «открывают» благодаря Groovy, Scala для себя вещи которые в реальности существуют давно. Но только вот польза от этих обёрток и интерпретаций сомнительна, зачем пользоватся пересказом если есть возможность работать с оригиналом. В Groovy я не вижу никаких новых идей для того чтобы туда пришли люди с другим опытом, да Java-сты будут использовать потому что они были лишены этих возможностей, но остальным это не интересно и Java остаётся замкнутым на себя сообществом.
Нельзя забывать, что Groovy фактически поддерживает синтаксис Java и поддерживает полный доступ к библиотекам Java. Это очень большой плюс для перехода. Сами же выше указали, что разработчики мигрируют очень неохотно. А тут практически и мигрировать не надо. ;)
Вы сильно заблуждаетесь относительно JPython и JRuby. У меня сложилось такое впечетление, что в программировании вы разбираетесь довольно поверхностно. Знаете зачем нам Jython? Думаете, чтобы кодить на нём, да? Нафига? Jython открывает доступ к огромному количеству Python библиотек из Java и наоборот. И как дополнительный бонус, возможность взаимодействовать программистам python, java, ruby. Думаете нам нужна Django или RoR? Ну может кому-то и нужна, правда тогда этот человек не в курсе последних фреймворков для java, которые на уровне Django или RoR.
Да, java фреймворки типа hibernate довольно сложны в изучении, но лишь потому, что они дают много больше возможностей для оптимизации и гибкости проектирования приложения. В отличии от простоты ORM Django или RoR. Хотите простоты? Тогда потеряете в чём то другом.
Да, java фреймворки типа hibernate довольно сложны в изучении, но лишь потому, что они дают много больше возможностей для оптимизации и гибкости проектирования приложения. В отличии от простоты ORM Django или RoR. Хотите простоты? Тогда потеряете в чём то другом.
Впрочем, конечно я не против, чтобы моё приложение было простым и в тоже время некий «искусственный интелект» динамически оптимизировал его под текущие требования. Но такого я не видел пока нигде. Так что простота django или ror — не больше, чем набор дефолтных настроек, актуальные для небольших проектов.
К сожалению я достаточно поработал с разными системами чтобы понимать что использовать нужно то что адекватно задачам. Я хочу укладыватся в ограничениям по времени, ресурсам денежным и техническим. Я не могу понять на кой чёрт мне многоядерные гигагерцовые монстры с кучей памяти для решения простых задач.
Да библиотеки Java поистину гигантские и иногда кажется что существуют для всего, но проблема как раз в том что эта громадность начинает мешать. Потому что даже в рамках одной библиотеки негласные контракты на использование хоронят под своей сложностью. Возможно это закономерный этап в эволюции комъютерных систем, но мне кажется что это тупик а не свет в конце тонеля.
Хотя каждый из нас останется при своём мнении, а результат эволюции будет виден лет за 5.
Да библиотеки Java поистину гигантские и иногда кажется что существуют для всего, но проблема как раз в том что эта громадность начинает мешать. Потому что даже в рамках одной библиотеки негласные контракты на использование хоронят под своей сложностью. Возможно это закономерный этап в эволюции комъютерных систем, но мне кажется что это тупик а не свет в конце тонеля.
Хотя каждый из нас останется при своём мнении, а результат эволюции будет виден лет за 5.
groovy компилируется в те же ява классы, это не интерпретатор в интерпретаторе
groovy уже достаточно давно используется в серьезных проектах
Ссылки?
www.groovyongrails.com/article/79 например
это непросто, ибо, полагаю, вы не часто видите на коммерческих сайтах детальное описание архитектуры и на чем там вообще внутри все написано.
лично я работал в таких проектах и там груви использовался уже два года назад.
кроме того, по косвенным данным:
1) IBM на даром начало такой проект www.projectzero.org/
2) простейший поиск вакансий в США по ключевому слову groovy возвращает, в том числе, вакансии в таких конторах, как Amazon и Boeing
лично я работал в таких проектах и там груви использовался уже два года назад.
кроме того, по косвенным данным:
1) IBM на даром начало такой проект www.projectzero.org/
2) простейший поиск вакансий в США по ключевому слову groovy возвращает, в том числе, вакансии в таких конторах, как Amazon и Boeing
По пункту 2 — вы эти вакансии смотрели? Тот же Боинг — то что висит на dice.com?
смотрел. на другом сайте, но вакансия та же.
знакомых архитектов из боинга у меня нет, чтобы точно выяснить, какую же роль у них играет груви и прочие питоны :)
знакомых архитектов из боинга у меня нет, чтобы точно выяснить, какую же роль у них играет груви и прочие питоны :)
Просто на том же дайсе среди семи сотен вакансий по Ruby уже после первой сотни идёт спам, где Ruby один из 10 языков в списке «не помешает опыт с...».
Практика показывает, что выбор технологии это 80% политики — пока что за Groovy/Ruby/Python/Scala не стоят серьёзные компании.
Нужного количество специалистов тоже нет. Не так много людей учат новые языки после института. Хотя вот Хортсман(тот что Core Java написал) начинает преподавать Scala как основной язык в университете у себя в Сан Хосе.
У Scala есть неплохой шанс из-за Actors Model, но и тут есть несколько «но».
Практика показывает, что выбор технологии это 80% политики — пока что за Groovy/Ruby/Python/Scala не стоят серьёзные компании.
Нужного количество специалистов тоже нет. Не так много людей учат новые языки после института. Хотя вот Хортсман(тот что Core Java написал) начинает преподавать Scala как основной язык в университете у себя в Сан Хосе.
У Scala есть неплохой шанс из-за Actors Model, но и тут есть несколько «но».
Всё зависит от потребностей пользователей.
Когда я слышу о том, как люди перешли с Java/.NET на Rails и как всё стало просто, то я во многом уверен — что Java им и не была нужна, а свои задачи они могли спокойно реализовать и на Python/PHP, а не использовать для этого Struts. Новые языки являются более узко-направленными и завоёвывают нишу за счёт простоты применения в определённых условиях, так PHP — DSL for Web Pages & Ruby — DSL for Web Applications.
Борьба в «динамическом» секторе(Groovy, Ruby, Python, PHP) довольно жёсткая — каждая из технологий имеет свои плюсы, но явного лидера среди них нет. Что касается «статического» сектора — тут есть только Scala, язык хороший, но сложный. В общем, прорыва какого-то из выше-перечисленных языков не будет, но свои, пусть и не большие, части рынка они получат.
Когда я слышу о том, как люди перешли с Java/.NET на Rails и как всё стало просто, то я во многом уверен — что Java им и не была нужна, а свои задачи они могли спокойно реализовать и на Python/PHP, а не использовать для этого Struts. Новые языки являются более узко-направленными и завоёвывают нишу за счёт простоты применения в определённых условиях, так PHP — DSL for Web Pages & Ruby — DSL for Web Applications.
Борьба в «динамическом» секторе(Groovy, Ruby, Python, PHP) довольно жёсткая — каждая из технологий имеет свои плюсы, но явного лидера среди них нет. Что касается «статического» сектора — тут есть только Scala, язык хороший, но сложный. В общем, прорыва какого-то из выше-перечисленных языков не будет, но свои, пусть и не большие, части рынка они получат.
Ruby — это не DSL для веб-приложений.
Новые языки не являются более узконаправленными. Все они являются general purpose languages.
Простота применения в определенных условиях достигается не из-за «заточенности» языка на определенную задачу, а из-за гибкости и динамичности самого языка.
Новые языки не являются более узконаправленными. Все они являются general purpose languages.
Простота применения в определенных условиях достигается не из-за «заточенности» языка на определенную задачу, а из-за гибкости и динамичности самого языка.
Я говорю непосредственно о реальном применении языков и вакансиях. Я знаю, что на Ruby какие-только проекты не писали — от баз данных до VOIP-фреймворков. Другой вопрос стоит в том, что выстрелило, а что нет: одного языка мало, нужны продукты и сообщества.
Нельзя рассматривать язык отдельно от библиотек для него написанных.
Что стоит Perl без CPAN.
Кто заинтересовался бы Ruby без Rails (а тот же немыслимы без ActiveRecords patterns).
Язык програмирования библиотек, как ОС без приложений, она может быть очень красивой но безполезной. Пока для того же Ruby не было создано критической масы библиотек mainstream его дружно игнорировал, сравните с тем же Python, в конце 90-х начале 2000-х Ruby по упоминаниям раз в 100 проирывал Python-у. Но появился Rails и многократно возросли упоминания Ruby увеличилось его использование и язык начал динамичнее развиваться. Более того к Python-у в сфере интереса к динамическим языкам тоже возрос интерес, а Python получив достойного конкурента тоже стал активнее развиватся, происходит перекрёсное опыление.
Второе дыхание получили также функциональные языки Haskell, Erlang, тот же Erlang кто бы им интересовался не будь на нём написан один из лучших xmpp-серверов ejabberd.
Что стоит Perl без CPAN.
Кто заинтересовался бы Ruby без Rails (а тот же немыслимы без ActiveRecords patterns).
Язык програмирования библиотек, как ОС без приложений, она может быть очень красивой но безполезной. Пока для того же Ruby не было создано критической масы библиотек mainstream его дружно игнорировал, сравните с тем же Python, в конце 90-х начале 2000-х Ruby по упоминаниям раз в 100 проирывал Python-у. Но появился Rails и многократно возросли упоминания Ruby увеличилось его использование и язык начал динамичнее развиваться. Более того к Python-у в сфере интереса к динамическим языкам тоже возрос интерес, а Python получив достойного конкурента тоже стал активнее развиватся, происходит перекрёсное опыление.
Второе дыхание получили также функциональные языки Haskell, Erlang, тот же Erlang кто бы им интересовался не будь на нём написан один из лучших xmpp-серверов ejabberd.
расскажите, если есть Groovy, зачем нужен JRuby?
чтобы запускать существующий ruby-код на Java-платформе
Нельзя забывать о том, что Rails — гораздо более зрелый проект, чем Grails и для него существует много вкусностей, которые пока не доступны в последнем. JRuby фактически имеет смысл только из-за Rails. Хотя лично мне JRuby действительно уже не кажется актуальным.
это все же как-то безумно маргинально… кому нужны все возможности «точно как в рельсах», скорее всего возьмут RoR. Grails и то вещь довольно умеренной популярности.
наверное можно представить себе извращенцев, которые хотят рельсы, но при этом хотят связать их с существующим Java-backend'ом
Прозрачное взаимодействие с Java, видимо, тоже многого стоит. Вот уж на чём действительно много существующего кода. :) Хотя делать умный вид не буду, ибо на Ruby писал мало, а про JRuby только читал.
насколько я знаю, более зрел он только с точки зрения фич именно rails, но никак не с точки зрения удобства/стабильности хостинга или самого языка ruby
«Переопределение операторов» и «Создание собственных конструкций языка» — мне казалось, что это то от чего пытались избавиться, создавая Java…
Статья очень хорошая(написана без приоритетов), но сразу возникнет вопрос: «Так что же выбрать? Scala, Groovy или JRuby?»
Что касается примеров на Scala — то они отлично показывают, как статически типизированный язык может стоять на равне по выразительности с динамическими, сохраняя недоступные им более высокую производительность и более богатые возможности для анализа кода.
К сожалению функциональная сторона Scala показана слабо.
Читателю может быть не ясно, почему implicit в Scala многословнее MOP модели Ruby. Коротко: изменяя объекты в Ruby вы меняете их во всём приложении. Scala позволяет вам к одному и тому же объекту добавлять методы, которые будут доступны только в отдельных его частях — тем самым при подключении сторонней библиотеки вы можете быть спокойны, что никто вам не принесёт неожиданностей в базовых классах.
Что касается примеров на Scala — то они отлично показывают, как статически типизированный язык может стоять на равне по выразительности с динамическими, сохраняя недоступные им более высокую производительность и более богатые возможности для анализа кода.
К сожалению функциональная сторона Scala показана слабо.
Читателю может быть не ясно, почему implicit в Scala многословнее MOP модели Ruby. Коротко: изменяя объекты в Ruby вы меняете их во всём приложении. Scala позволяет вам к одному и тому же объекту добавлять методы, которые будут доступны только в отдельных его частях — тем самым при подключении сторонней библиотеки вы можете быть спокойны, что никто вам не принесёт неожиданностей в базовых классах.
Меня Scala давно интересует, но надо найти хорошее руководство. Статья на RSDN мне в своё время показалась весьма жёсткой, хотя и мозгонаполняющей.
Забыл сказать, что в Groovy тоже можно ограничить область действия добавленного метода или преопределённого оператора:
class StringCalculationCategory {
static def plus(String self, String operand) {
return self.toInteger() + operand.toInteger()
}
}
use (StringCalculationCategory) {
assert 1 == '1' + '0'
}
ну, скорость groovy — это один из немногих его недостатков
речь не о полях, а о пропертях. т.е. полях с доступом через стандартные геттеры-сеттеры.
груви их генерит автоматом
груви их генерит автоматом
В коде груви их нет в явном виде, но на самом деле они есть :)
если вы хотите добавить валидацию в сеттер, таки придется его описать
если вы хотите добавить валидацию в сеттер, таки придется его описать
на моей практике в 90% геттеры-сеттеры в ява коде не содержат никакой доп.логики
т.е. груви как раз закрывает этот случай
т.е. груви как раз закрывает этот случай
Разделите два понятия: синтаксис языка и получаемый байт-код. Тогда плюс Groovy станет понятен: одной строкой генерится байт-код, который на Java можно получить только несколькими строками. Ввиду того, что свойства используются повсеместно, это даёт ощутимый выигрыш в объеме кода и простоте поддержки. Это, кстати, не приводит к нарушению инкапсуляции (в отличие от public-полей). И если вдруг понадобится усложнение getter или валидация в setter, вы можете их добавить совершенно не нарушая совместимости. Код, зависящий от вашей библиотеки, не надо будет перекомпилировать.
да, просто указать модификатор доступа к полю и будет просто поле.
типа
private def price
protected String name
там по умолчанию поля public и с геттерами-сеттерами
типа
private def price
protected String name
там по умолчанию поля public и с геттерами-сеттерами
ась? очень даже превратится, ибо никакого доп.кода геттеров не будет создано.
даже если вы просто укажете public — геттеры не будут созданы для вас.
read-only свойство выглядит вот так
final String name = «John»
если вы хотите менять его изнутри, но закрыть снаружи, то объявляете его public и ручками пишете только геттер
даже если вы просто укажете public — геттеры не будут созданы для вас.
read-only свойство выглядит вот так
final String name = «John»
если вы хотите менять его изнутри, но закрыть снаружи, то объявляете его public и ручками пишете только геттер
совершенно идентично яве
а вы это всё к чему клоните?
а вы это всё к чему клоните?
public int getItemCount() { return myList.size() }
если я правильно понял, что вы ходите сделать
если я правильно понял, что вы ходите сделать
гы. а вы погуглите, на счет общего определения пропертей в языках, боюсь, узнаете много нового.
я вот вам кусочек процитирую:
property must have some attribute that makes it instantly recognizable as such and distinguishable from other values that are not properties.
так вот, в яве принято проперти описывать в виде методов со сторого определенным именованием
я вот вам кусочек процитирую:
property must have some attribute that makes it instantly recognizable as such and distinguishable from other values that are not properties.
так вот, в яве принято проперти описывать в виде методов со сторого определенным именованием
это очень сильная договоренность, ибо явовские проперти доступны для интроспекции языковыми средствами.
нигде не сказано, что проперть от поля обязана быть неотличима по доступу
в общем, это все в рамках нормальных языковых различий
нигде не сказано, что проперть от поля обязана быть неотличима по доступу
в общем, это все в рамках нормальных языковых различий
Package java.beans
да что вы говорите? а java.lang.Class имеет отношение?
мягко говоря спорно сводить «язык» только к синтаксическим конструкциям
мягко говоря спорно сводить «язык» только к синтаксическим конструкциям
А вы сами внимательно посмотрите чем является свойство в IL. ;)
Несмотря на дополнительные мета-данные это всего-навсего метод.
Несмотря на дополнительные мета-данные это всего-навсего метод.
ну и что, где тут отличие от Джавы? Отличие в том, что больше помойки с полями классов?
В джаве все поля класса по умолчанию доступны классам в том же пакете и наследникам.
Принципиальной разницы-то нет.
В джаве все поля класса по умолчанию доступны классам в том же пакете и наследникам.
Принципиальной разницы-то нет.
а разве где-то сказано, что это главное отличие и достижение и вообще смысл груви? :))
Я в общем, про статью!
Простота объявления свойств (properties) у языков Java.next
Я как бы протестую, показывая, что и в Жабе можно все упростить и получится не намного больше.
Простота объявления свойств (properties) у языков Java.next
Я как бы протестую, показывая, что и в Жабе можно все упростить и получится не намного больше.
типичная ситуация, когда дефолтные аксессоры занимают 3/4 объема класса-сущности
ну пусть у класса есть всего 2 разных поля, это порождает аж 4 различных конструктора.
в groovy конструктор можно вообще не объявлять.
в groovy конструктор можно вообще не объявлять.
Можно меня дальше минусовать, но сути дела это не меняет:
Груви, это та же Жаба, только в профиль.
И в Жабе можно не объявлять конструктор, что в общем-то логично, достойное дитятко переняло много хорошего по наследству (cейчас на http://groovy.codehaus.org/ побывал.).
Мне наша беседа напоминает разговор глухого с немым: я вообще не в курса, что такое Руби, Груви и т.д., немножко JPython знаю, писал на нем кусочки скриптов для IBM'овского сервачка.
Мои собеседники, рьяно защищающие Руби, груви и Ко не знаю Жабы.
Я полагаю,
и
одно и тоже лицо?
В общем, вывод можно сделать такой — не принимать статью близко к сердцу и поковырять, например, Ruby, JRuby и Ruby on Rails и понять, что это такое, и нужно ли оно мне вообще.
Груви, это та же Жаба, только в профиль.
И в Жабе можно не объявлять конструктор, что в общем-то логично, достойное дитятко переняло много хорошего по наследству (cейчас на http://groovy.codehaus.org/ побывал.).
Мне наша беседа напоминает разговор глухого с немым: я вообще не в курса, что такое Руби, Груви и т.д., немножко JPython знаю, писал на нем кусочки скриптов для IBM'овского сервачка.
Мои собеседники, рьяно защищающие Руби, груви и Ко не знаю Жабы.
Я полагаю,
и
одно и тоже лицо?
В общем, вывод можно сделать такой — не принимать статью близко к сердцу и поковырять, например, Ruby, JRuby и Ruby on Rails и понять, что это такое, и нужно ли оно мне вообще.
Все, понял! Спасибо большое за хороший пример!
Я считаю, что всякая автогенерация кода в IDE для какого-то языка означает, что в этом месте язык хромает. Неспроста вводится автоматическая вставка кода.
В Java ну оооочень часто приходится плодить геттеры и сеттеры, лишь потому, что обращение напрямую к полям класса — моветон, типа инкапсуляция и все дела. Забавно выглядят бины, которые только таскают данные от одного слоя к другому. Никакого толку, зато куча кода.
Груви избавляет от этого геморроя. Второй пример — браво!
Что-ж, дельное решение, спору нет!
Я считаю, что всякая автогенерация кода в IDE для какого-то языка означает, что в этом месте язык хромает. Неспроста вводится автоматическая вставка кода.
В Java ну оооочень часто приходится плодить геттеры и сеттеры, лишь потому, что обращение напрямую к полям класса — моветон, типа инкапсуляция и все дела. Забавно выглядят бины, которые только таскают данные от одного слоя к другому. Никакого толку, зато куча кода.
Груви избавляет от этого геморроя. Второй пример — браво!
Что-ж, дельное решение, спору нет!
>Груви, это та же Жаба, только в профиль.
ну в какой-то степени да, в этом и есть главный плюс groovy по сравнению с JRuby и Scala — не нужно переучиваться с нуля, можно постигать всё постепенно
ну в какой-то степени да, в этом и есть главный плюс groovy по сравнению с JRuby и Scala — не нужно переучиваться с нуля, можно постигать всё постепенно
В Groovy необязательно объявлять конструктор из-за приятной возможности:
И, так уж и быть, открою самую тёмную сторону Groovy: он отучает использовать точку с запятой, что потом может вылезать боком. ;)
class A {
def b
def c
def d
}
def a = new A(b:0, c:1)
И, так уж и быть, открою самую тёмную сторону Groovy: он отучает использовать точку с запятой, что потом может вылезать боком. ;)
В вашем примере нет свойств и нарушена инкапсуляция.
Можно «дорисовать» на ходу: www.playframework.org/manual/contents/model ;)
Я не понимаю, почем вас минусуют, я привел тот же пример. Я с вами согласен.
Не хочется писать геттеры и сеттеры, используйте public поля.
В общем, утверждение про поля — спорное.
Не хочется писать геттеры и сеттеры, используйте public поля.
В общем, утверждение про поля — спорное.
в груви person.lastName = «John» — это сеттер, а прямой доступ к полю — это person.'@lastName' = «John»
впрочем, это не раскрывает преимуществ groovy, а придумать хороший пример что-то я сходу не могу :(
впрочем, это не раскрывает преимуществ groovy, а придумать хороший пример что-то я сходу не могу :(
В Java нам ежедневно приходится сталкиваться с разницей между объектами и примитивами. Это порождает три практические проблемы:
Приходится дублировать API: один метод для объектов и ещё один для примитивов. Или, что ещё хуже, один метод для объектов и по методу для нескольких типов-примитивов.
А ка как же автоупаковка и распаковка, появившиеся в 1.5?
В Java для того, чтобы создать свойство вы должны определить поле, getter, setter, и (довольно часто) конструктор, причём везде прописать правильные модификаторы доступа. В Java.next, вы можете определить всё это одним шагом.
Пример в Java:
public class Person{
public String name;
public Integer age;
//дефолтовый конструктор() дописывается компилятором, если нет иного.
}
//…
Person person = new Person();
int age = person.age; //автораспаковка
Числовые типы, используемые по умолчанию, имею ограниченный диапазон. Выйдите за его рамки — и программа сломается волшебным образом.
Вовсе не волшебным. Какое-то странное утверждение. К тому же в Джаве есть спецальный класс — BigInteger, с помощью которого можно работать с очень большими числами.
Например, чтобы найти все возведённые в квадрат значения от единицы до десяти, которые нечётны можно сделать следующее:
ИМХО код вообще нечитаемый. Может, это круто — писать всю программу или функцию в одну строку, но «последователям» такого программиста придется туго.
Переопределение операторов
Языки Java.next позволяют вам переопределять операторы. Это даёт возможность создавать новые типы, которые воспринимаются так же как и встроенные. Т.е. вы можете создать типы ComplexNumber или RationalNumber, которые поддерживают операции +, -, *, и /.
Вот это круто, но для узкоспециализированных программ, например, для тех, чт что-то очень много считают.
Я представляю себе другую ситуацию — работает 10 программистов над проектом, периодически из этих 10ти несколько человек уходит, приходят новые. Все программисты, порой, переопределяют операторы. И вот, в одном модуле программы минус, это минус. а в другом — минус выполняет что-то еще. Это взрыв мозга, каша и мешанина.
Имхо переопредление плюса со сложения чисел на конкатенацию, самое удобное. Все остальное — спорно, т.к. не очевидно.
Легкость в поддержке исключений
Checked exceptions оказались неудачным экспериментом. Код Java из-за них лишь разбухает, ничем особо не способствуя улучшению обработки ошибок. Хуже того, checked exceptions являются настоящей головной болью для поддержке на границе между слоями абстракций. Введение новых типов исключений не должно приводить к перекомпиляции!
Вообще не понял, что автор хотел сказать. Засирать checked exceptions — глупо. Все отальное — непонятно.
По моему опыту, этот стиль кодирования приводит к уменьшению размера исходников на порядок без снижения читабельности.
Ну это автор перегнул.
В Java вы не можете доблять методы к существующим типам. Это ведёт к проблемам в моделировании объектов, когда разработчикам приходится создавать вспомогательные (utility) классы, которые нарушают принципы ООП:
Это враки, я могу это делать, но ряд классов, например String, защищены от модифицирования. И сделано это не из вредности, а по определенных причинам.
Большое спасибо за перевод! Хорошо получилось! Спорная, интересная статья. Однозначно плюс!
Но ошибки есть:
Про мощные коллекции —
For example, to find the all the squares under 100 that are also odd:
Например, чтобы найти все возведённые в квадрат значения от единицы до десяти, которые нечётны можно сделать следующее:
Речь идет о том, чтобы найти все квадраты простых чисел (0 до 9), которые меньше 100 и нечетны.
Есть и другие, не успел написать, можт позже напишу.
Приходится дублировать API: один метод для объектов и ещё один для примитивов. Или, что ещё хуже, один метод для объектов и по методу для нескольких типов-примитивов.
А ка как же автоупаковка и распаковка, появившиеся в 1.5?
В Java для того, чтобы создать свойство вы должны определить поле, getter, setter, и (довольно часто) конструктор, причём везде прописать правильные модификаторы доступа. В Java.next, вы можете определить всё это одним шагом.
Пример в Java:
public class Person{
public String name;
public Integer age;
//дефолтовый конструктор() дописывается компилятором, если нет иного.
}
//…
Person person = new Person();
int age = person.age; //автораспаковка
Числовые типы, используемые по умолчанию, имею ограниченный диапазон. Выйдите за его рамки — и программа сломается волшебным образом.
Вовсе не волшебным. Какое-то странное утверждение. К тому же в Джаве есть спецальный класс — BigInteger, с помощью которого можно работать с очень большими числами.
Например, чтобы найти все возведённые в квадрат значения от единицы до десяти, которые нечётны можно сделать следующее:
ИМХО код вообще нечитаемый. Может, это круто — писать всю программу или функцию в одну строку, но «последователям» такого программиста придется туго.
Переопределение операторов
Языки Java.next позволяют вам переопределять операторы. Это даёт возможность создавать новые типы, которые воспринимаются так же как и встроенные. Т.е. вы можете создать типы ComplexNumber или RationalNumber, которые поддерживают операции +, -, *, и /.
Вот это круто, но для узкоспециализированных программ, например, для тех, чт что-то очень много считают.
Я представляю себе другую ситуацию — работает 10 программистов над проектом, периодически из этих 10ти несколько человек уходит, приходят новые. Все программисты, порой, переопределяют операторы. И вот, в одном модуле программы минус, это минус. а в другом — минус выполняет что-то еще. Это взрыв мозга, каша и мешанина.
Имхо переопредление плюса со сложения чисел на конкатенацию, самое удобное. Все остальное — спорно, т.к. не очевидно.
Легкость в поддержке исключений
Checked exceptions оказались неудачным экспериментом. Код Java из-за них лишь разбухает, ничем особо не способствуя улучшению обработки ошибок. Хуже того, checked exceptions являются настоящей головной болью для поддержке на границе между слоями абстракций. Введение новых типов исключений не должно приводить к перекомпиляции!
Вообще не понял, что автор хотел сказать. Засирать checked exceptions — глупо. Все отальное — непонятно.
По моему опыту, этот стиль кодирования приводит к уменьшению размера исходников на порядок без снижения читабельности.
Ну это автор перегнул.
В Java вы не можете доблять методы к существующим типам. Это ведёт к проблемам в моделировании объектов, когда разработчикам приходится создавать вспомогательные (utility) классы, которые нарушают принципы ООП:
Это враки, я могу это делать, но ряд классов, например String, защищены от модифицирования. И сделано это не из вредности, а по определенных причинам.
Большое спасибо за перевод! Хорошо получилось! Спорная, интересная статья. Однозначно плюс!
Но ошибки есть:
Про мощные коллекции —
For example, to find the all the squares under 100 that are also odd:
Например, чтобы найти все возведённые в квадрат значения от единицы до десяти, которые нечётны можно сделать следующее:
Речь идет о том, чтобы найти все квадраты простых чисел (0 до 9), которые меньше 100 и нечетны.
Есть и другие, не успел написать, можт позже напишу.
О, блин, пока писал, уже 30 комментов сделали!
В тексте действительно было про все квадраты меньше 100, но поскольку в коде используется диапазон значений от 1 до 10 (а не число 100), то я счёл более корректным перевести как перевёл. Так точнее. О простых числах там ничего не говорится, кстати.
> Вот это круто, но для узкоспециализированных программ, например, для тех, чт что-то очень много считают.
Я представляю себе другую ситуацию — работает 10 программистов над проектом, периодически из этих 10ти несколько человек уходит, приходят новые. Все программисты, порой, переопределяют операторы. И вот, в одном модуле программы минус, это минус. а в другом — минус выполняет что-то еще. Это взрыв мозга, каша и мешанина.
Имхо переопредление плюса со сложения чисел на конкатенацию, самое удобное. Все остальное — спорно, т.к. не очевидно.
debasishg.blogspot.com/2008/02/why-i-like-scalas-lexically-scoped-open.html — смотрите шире
Я представляю себе другую ситуацию — работает 10 программистов над проектом, периодически из этих 10ти несколько человек уходит, приходят новые. Все программисты, порой, переопределяют операторы. И вот, в одном модуле программы минус, это минус. а в другом — минус выполняет что-то еще. Это взрыв мозга, каша и мешанина.
Имхо переопредление плюса со сложения чисел на конкатенацию, самое удобное. Все остальное — спорно, т.к. не очевидно.
debasishg.blogspot.com/2008/02/why-i-like-scalas-lexically-scoped-open.html — смотрите шире
>функции как первоклассные объекты
улыбнуло :)
по теме:
если честно, то я не понимаю, зачем нужно jruby при налиции groovy и почемы сан развивает именно его :(
кстати в Groovy нет нужны в методе isBlank для стрингов и не только, там весьма удобно переопределено «true-false» для многих объектов
за статью — спасибо!
улыбнуло :)
по теме:
если честно, то я не понимаю, зачем нужно jruby при налиции groovy и почемы сан развивает именно его :(
кстати в Groovy нет нужны в методе isBlank для стрингов и не только, там весьма удобно переопределено «true-false» для многих объектов
за статью — спасибо!
Groovy-пользователи никуда не убегут, а рубистов можно на глассфиш посадить со всеми вытекающими $.
сан вообще много странного делал и делает.
тот же JavaFX можно было на груви делать…
тот же JavaFX можно было на груви делать…
да, groovy куда ближе у java, чем javafx
Ну как сообщество вытащило провальный j2ee 1.4 на новый уровень(hibernate является реализацией jee 5, seam делает удобными jsf, а spring будет реализацией jee 6), так Google со своим GWT & Chrome уже представляет великолепный RIA фреймворк.
JavaFX даст нам долгожданную поддержку мультимедии на JRE, а что касается JavaFX Script — я бы его заменил на JavaScript(в ES4 есть поддержка статических типов), либо сделал бы многоязычным как Silverlight.
JavaFX даст нам долгожданную поддержку мультимедии на JRE, а что касается JavaFX Script — я бы его заменил на JavaScript(в ES4 есть поддержка статических типов), либо сделал бы многоязычным как Silverlight.
вернее, hibernate — одна из реализаций JPA, сильно повлиявшая на ее спецификацию,
на счет спринга, как реализации jee6, я вообще избегаю особой радости, ибо это достаточно далеко от реальных lightweight идеалов
ну а от GWT вообще многие плюются :)
на счет спринга, как реализации jee6, я вообще избегаю особой радости, ибо это достаточно далеко от реальных lightweight идеалов
ну а от GWT вообще многие плюются :)
ну я обобщил для целостности картины. spring со всем его арсеналом является относительно лёгким, да и от версии к версии местами становится проще — после того как ввели аннотации вообще легко живётся. gwt, наряду с wicket — два моих любимых компонентных фреймворка для java, в продакшн на нём ничего не писал, но после пользования довольно приятные впечатления.
А, вот, не могли бы вы теги запятыми разделить? Иначе они работать не будут :)
Это все классно и действительно интересно, меня сильно заботит только один вопрос: насколько это все быстро работает? И — насколько эффективно это все работает с памятью?
scala — очень быстро, по памяти не знаю.
groovy — не очень быстро, пока что отставание в несколько раз, но работы над этим ведутся весьма активные.
jruby — хуже, чем в groovy, насколько — не знаю
groovy — не очень быстро, пока что отставание в несколько раз, но работы над этим ведутся весьма активные.
jruby — хуже, чем в groovy, насколько — не знаю
Хм. Надо посмотреть будет.
Сейчас есть такая тенденция, что именно в среде высоконагруженных систем главным bottleneck'ом выступает именно неэффективная работа с памятью (хотя в первую очередь это касается кода, написанного программистом, однако же язык и фреймворки тоже вносят свой вклад — достаточно вспомнить про знаменитую «пилу» J2EE/EJB систем).
Сейчас есть такая тенденция, что именно в среде высоконагруженных систем главным bottleneck'ом выступает именно неэффективная работа с памятью (хотя в первую очередь это касается кода, написанного программистом, однако же язык и фреймворки тоже вносят свой вклад — достаточно вспомнить про знаменитую «пилу» J2EE/EJB систем).
Вот-вот. Java программа, если мне память не изменяет, меньше 25 мегабайт памяти уже не занимает и запускается не мгновенно, а что с этими языками будет…
И, кстати, работать быстрее современные языки, видимо, не будут, проще заставить пользователя покупать новое железо, чем заниматься оптимизацией((
За что только программиистам деньги платят?
И, кстати, работать быстрее современные языки, видимо, не будут, проще заставить пользователя покупать новое железо, чем заниматься оптимизацией((
За что только программиистам деньги платят?
Спасибо за интересную статью!
Хочу кое-что прокомментировать.
Checked exceptions оказались неудачным экспериментом. Код Java из-за них лишь разбухает, ничем особо не способствуя улучшению обработки ошибок.
Не соглашусь. Мне кажется, их очень даже стоит использовать, например, когда клиенты метода сами не могут проверить, можно ли выполнить метод при данных параметрах (например, при работе с файловой системой или сетью). Так клиент метода никогда не забудет обработаь ошибку.
Хуже того, checked exceptions являются настоящей головной болью для поддержке на границе между слоями абстракций. Введение новых типов исключений не должно приводить к перекомпиляции!
Если вы имеете в виду, что бросание какого-нибудь SaxParserException в методе readSomething, нарушает инкапсуляцию, то эта проблема решается просто созданием своего типа исключения и оборачиванием нежелательных исключений в него.
Хочу кое-что прокомментировать.
Checked exceptions оказались неудачным экспериментом. Код Java из-за них лишь разбухает, ничем особо не способствуя улучшению обработки ошибок.
Не соглашусь. Мне кажется, их очень даже стоит использовать, например, когда клиенты метода сами не могут проверить, можно ли выполнить метод при данных параметрах (например, при работе с файловой системой или сетью). Так клиент метода никогда не забудет обработаь ошибку.
Хуже того, checked exceptions являются настоящей головной болью для поддержке на границе между слоями абстракций. Введение новых типов исключений не должно приводить к перекомпиляции!
Если вы имеете в виду, что бросание какого-нибудь SaxParserException в методе readSomething, нарушает инкапсуляцию, то эта проблема решается просто созданием своего типа исключения и оборачиванием нежелательных исключений в него.
По поводу добавления методов к существующим типам. Я как-то придумал такую штуку (применительно к C++)
method string ExpandFileName(const std:: string& s)
{
…
}
И тогда можно писать не ExpandFileName(s), а s.ExpandFileName(). Естественно, ничего виртуального, да и новое поле к объекту не приклеишь.
Мечты, мечты… Впрочем, как говорит Lite, в новых языках программирования это уже есть (не знаком).
method string ExpandFileName(const std:: string& s)
{
…
}
И тогда можно писать не ExpandFileName(s), а s.ExpandFileName(). Естественно, ничего виртуального, да и новое поле к объекту не приклеишь.
Мечты, мечты… Впрочем, как говорит Lite, в новых языках программирования это уже есть (не знаком).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Java.next: Общие принципы языков нового поколения