Дык в том и то и дело что cefglue или geckofx или другие обертки это всего лишь interop обертки, со всеми отсюда вытекающими последствиями, не говоря уже про отсутствие поддержки x64, хотя в нативном варианте она есть но в найтбилдах.
Будучи c#-ером я завидовал цэ++-серам так как у вас есть cef для работы с webkit-ом. А у авсомема лицензия корявая и апдейтится он нечасто (так было раньше).
Ну все смешали и мясо и железо, хотя наверное если оставить только железо то никто на такие презентации помимо отпетых гигков ходить не будет. Хотя могли бы мясо и получше завернуть а то непонятно куда ты попал, благо этикетки на мясе есть.
Личное дело каждого из нас, я встречал народ который писал на java с использованием vim или textmate без особой поддержки ide. Потому что для этих людей главным минусом eclipse была его супер тяжеловесность.
Хм я лишь сказал что eclipse это так же безнадежно как ie6 или cobol. Я сравниваю не их самих а просто подвожу общую черту — no future. Я понимаю что вам может быть обидно, так же как эти слова могут быть обидны программисту cobol но факты говорят сами за себя. В плане eclipse это то что текущие версии этого продукта построены на eclipse 3.0 который почти ровесник IE6. Я не думаю что это удачное место обсуждения недостатков умирающего eclipse. От себя могу лишь добавить что мне лично было очень обидно из-за не имения возможности использования Intellij CE писать расширения для eclipse, храни вас всех Бог от такого удовольствия. Я солидарен в данном аспекте с гуглмэнами, они наверное на 7 небе от счастья после перехода с расширения для eclipse на использование кодовой базы Intellij CE.
Неплохо, очень неплохо молодцы ребята. Единственное нарекание в сторону гугла за то что им столько времени понадобилось что бы понять что eclipse это безнадежно как ie6 (кстати ядро современного eclipse почти ровесник ie6). Ведь Intellij CE уже давно существует где же гугл был раньше?
Про корректный подход народ уже написал выше. Если вы себе поставили цель выучить язык C# то советую вам не терять времени на такого рода сомнительные авантюры. Попробуйте например поучаствовать в опенсорсном проекте там вам и существующий код как гидлайн и «гуру» которые в любой момент подскажут вам что не так с вашим кодом и наконец хоть какая то польза.
Спасибо за исчерпывающий ответ. Теперь увидел разницу. Если мне не изменяет память то в плане юнити использование IoC например по средствам работы с конструкторами по сравнению с Service Locator будет немного более медленным особенно там где будет присутствовать вложенная инициализация. Но в целом подход намного чище чем Service Locator.
Я недавно ознакомился с трудом Seemann Mark под названием Dependency Injection in .NET. Не знаю какой вес имеет данный автор в мире .net но меня удивил тот факт что он прямо таки приравнял Service Locator к анти-паттернам. Признаюсь я использую в моих проектах юнити в купе с паттерном Service Locator но как-то не совсем представляю как обойтись без оного или чем заменить. В своих примерах автор часто создает экземпляр контейнера, для объяснения это подходит но для реал-ворлд приложения не очень. Что скажет автор по данному поводу? Спасибо
Ну насколько я помну там вопрос стоял ребром, в 7рку не включили а восмерку планировали через год макс и поползли слухи что в связи с плотным графиком возможно… И тогда видимо народ взбунтовался и решили дату выхода 8 версии сдвинуть. Может я конечно ошибаюсь и это только слухи но изменение даты выхода имело место.
В play 1.* нет никакой поддержки dao весь автоматизм реализован для поддержки activerecord паттерна. Далее вы говорите про включение поддержки дао, я не знаю каким способом вы ее включаете но изначально play не предусматривает ничего такого. Вам приходися или все делать руками или же использовать готовый модуль.
Спасибо за информацию, но согласитесь что до последнего момента не было уверености что замыкания войдут в состав 8 версии и х как то уж усиленно двигали в сторону 9. Кстати не замыкания ли виноваты в сдвиге даты выхода 8 версии по сравнению с объявленными датами сразу после покупки java ораклом?
Насчет фич в моно есть все необходимое и за ним стоит солидная контора а уровень поддержки нисколько не отличается от j2se. Когда я говорю про склеивание ласт я имею ввиду только java как язык. Одерский как то сказал в одной из своих заметок что java который мы знаем уже давно исчерпал свои возможности а вот jvm нет и именно с ней и стоит работать и развивать ее. Например еклипс как всегда обгадился делая ставку на язык поверх java вместо jvm.
Дык на кобыле (cobol) тоже вон сколько всего написанно. А что собственно вам мешает Hadoop, Lucene итд портировать на c# получится гороздо лучше. Склеивание ласт начинается с забрасывания обогащения фич языка. А то что весь энтерпрайз сидит то заслуги прошлых лет и только sun и если ничего не предринять то будет поздно.
Плей как раз и не был задуман для работы с dao он предусматривал работу а ля рор с актив рекордом, а уш что там всякие доморощенные умелцы накрутили своими кривыми руками с dao то это на их и собственно ваш страх и риск.
Да а вы пробовали веб сокеты хостит на грейлз, он не чуть не легковеснее спринга, скорее наоборот. Оба этих продукта работают только с контейнерами сервлетов, что вас отбрасывает на столетия назад к комете и плохому симулированию асинхронизма. Для малых и простых проектов это некритично.
Согласен с вами, на мой взгляд с java дела обстоят точно так же как с cobol который до сих пор можно встретить во многих организациях например в крупных банках Люксембурга. Платформа будет существовать еще достаточно долго, наверное столько сколько будет спрос даже если большенство разработчиков будут отдавать предпочтения другим языкам.
Да сравнинте хотя бы фичи по датам выпуска в c# и java, там разница в несколько световых лет. Например если говорить про консервативный с++ до даже в его последнем стандарте есть поддержка closure а в java такая фича еще до сих пор под вопросом. Да это сугубо мое личное мение, может от части схожее с авторским. Если вы хотите тут развести троллоло то не советую.
Немного о политике. Если версия 2.0 курировалась и писалась в zenexity людьми очарованными haskell, f# и scala и которые не могли смотреть на java без рвотных позывов, то версия 2.1 дорабатывалась typesafe так как zenexity не выполнила своих прямых обязательств в срок. Сложно сказать будет ли в play 2.* нормальная поддержка java как в 1.*. Насколько мне известно typesafe определили на проект play именно scala разработчиков, да компания продвигает именно scala на рынке. Скорее всего поддержка java будет болтаться в проруби и в последующих версиях. С другой стороны что сегодня можно сделать с java, который безнадежно склеивает ласты.
Я недавно ознакомился с трудом Seemann Mark под названием Dependency Injection in .NET. Не знаю какой вес имеет данный автор в мире .net но меня удивил тот факт что он прямо таки приравнял Service Locator к анти-паттернам. Признаюсь я использую в моих проектах юнити в купе с паттерном Service Locator но как-то не совсем представляю как обойтись без оного или чем заменить. В своих примерах автор часто создает экземпляр контейнера, для объяснения это подходит но для реал-ворлд приложения не очень. Что скажет автор по данному поводу? Спасибо