Siemargl,

Вирт убрал разделение в REVISED OBERON

РАЗЛИЧИЯ МЕЖДУ OBERON’ом И ПЕРЕСМОТРЕННЫМ OBERON’ом (REVISED OBERON)

Пересмотр языка Oberon был произведен после большого числа экспериментов в использовании и реализации данного языка. И вновь этот процесс был вызван стремлением к упрощению и обобщению. Различия между исходной версией [Wir88b] и пересмотренной версией [Wir90] следующие.

1. Интерфейсная и исполнительная части модуля слиты воедино. Это вызвано желанием иметь спецификацию модуля с точки зрения программиста и с точки зрения компилятора в виде одного документа. Спецификация интерфейса для клиентов модуля (интерфейсная часть) может быть получена автоматически.

Объекты, ранее описываемые в интерфейсной части (и еще раз встречающиеся в исполнительной части), помечаются специальным значком экспорта.


Никлаус Вирт "От Модулы к Оберону"

Andy_OLAP,
я не юноша и вы выбрали неверный стиль общения, пытаясь взять криком. Я и юношей так с собой разговаривать не позволял, теперь тем более.

Да, заставляет, но они работают как должны. Как должны офицерам из подразделения,

1. В Гугле нет и не может быть никаких офицеров (даже если вы переводите английское слово чиновник неправильно - чиновников там тоже нет и быть не может). Это не армия и не государственная организация, а частная компания. Равноправная с любым юридическим лицом и не имеющая преференций перед частными лицами.
2. Что его работники должны Гуглу нужно слушать от самого Гугла, а не от вас.
3. Гугл пока еще вроде не заявлял, что его Студия не должна работать сразу после установки, не запускаться, выдавать ошибки в созданных ею же проектах, что grandlew может не запускаться и т. п.

Так что вы не правы - именно что не работает как должно. Не работает как заявлено, если вам от этого легче. Заявлено - используйте нашу песочницу и все будет работать без проблем. Даже это не выполняется.

Причем это закономерно - если разработчики считают, что могут всем выкрутить руки, удалить конкурентов и принудить работать на том, что они подсовывают, они стараться сделать что то вообще работающее не будут, мол и так сожрут - а всем недовольным мол заткнут роль с помощью нанятых агитаторов. Низкая квалификация видна невооруженным взглядом.

Я думаю, что несмотря на лживые победные реляции Гугл уже давно столкнулся с МАССОВЫМ нежеланием разработчиков использовать свою Студию. Поэтому руки и выкручивают, даже SDK manadger удалили из SDK. Чтобы отчитываться перед руководством компании о росте числа установок своей бракованной продукции. Ну а на ресурсах с порочной системы репутации сидят специально нанятые люди и минусуют любое недовольство этим продуктом.

Это напоминает анекдот о том, как цыган учил лошадь не есть.

В принципе, интересам Гугла бракоделие создателей студии противоречит, так как мешает заманивать разработчиков в капкан полной зависимости от себя. Куда проще им бы было, если бы сыр в мышеловке был сыром, а не куском грязи.

лиспа - оттуда взят код по сборке мусора

Нет, я имел в виду другое. Сборщик мусора тиснули из Оберона. Я имел в виду т. н. лямбда-функции, которые вносят еще больше хаоса в код на Яве.

Java - многопоточность там часть языка

В Java многопоточность не является частью языка. Считаете я неправ - тогда покажите, как вы будете создавать поток в Java, какие зарезервированные слова языка для этого используете.

интерпретируемый диалект языка Си++ изначально

В Java от C++ только скобочки и некоторые ключевые слова.

Я Вам более того скажу, принцип Java - классы вместо структур, а у Оберона с точностью до наоборот.

Это внешняя мишура. Класс - структура с данными, метод - процедура, которой передается указатель на экземпляр класса. Виртуальный метод - поле с указателем на процедуру. В Обероне есть расширение структур (наследование).

Надо обладать хотя бы минимальными способностями к абстрактному мышлению и некоторыми знаниями о реализации, чтобы это увидеть. Хотя все достаточно очевидно.

Просто я уже и не знаю, чего ожидать от современных т. н. "андроид-ява-программистов". Когда вместо статей ролики в ютубе (просмотр ролика занимает в 5-10 раз больше времени, чем чтение текста и информация на слух воспринимается куда хуже, чем с из текста), вместо изучения внутренней структуры - инструкции по магическим манипуляциям в IDE и за ее пределами.

Вирт книжный червь, а не инженер-прагматик

Вирт сам писал компиляторы и операционные системы всю свою жизнь. Внимание вопрос - что создал Джеймс Гослинг, какие программы написал?

Вот Ричи (один из создателей С), например, сделал ОС Unix, которая получила широкое распространение. Его можно назвать программистом-практиком.

Уж про гугловских вообще можно не говорить. Стырили свободную ОС, свободную виртуальную машину, объявили все своим и начали портить. При этом сначала создавая у программистов иллюзия открытости и противопоставления "плохим корпорациям", а потом решили намертво все закрыть, объявить своим и показать всем, кто им помогал, что плевать они на них хотят. Взяв чужую среду разработки.

Тут остается только удивляться распространенности Android-устройств и тому, что там есть работающие и использующиеся программы.

Поэтому я утвердился во мнении, что пишется это на чем то старом и/или стороннем, вопреки стараниям гугла и уж точно не на последней версии Студии.

Отсюда вывод - использовать Студию = быть лохом. Даже если программируешь под Андроид.

Siemargl,
Похоже в статье по вашей ссылке вы спутали объявление процедурного типа с объявлением функции. Советую почитать другие документы с того же сайта. В первоначальной редакции Оберона было разделение на открытую и закрытую части модуля, а в исправленной версии в 1990 году профессор Вирт это разделение убрал и больше к нему не возвращался (forward декларация это не то, она не является обязательной и служит другим целям).
Описание v90 https://www.inf.ethz.ch/personal/wirth/Oberon/Oberon.Report.pdf . На всякий случай поясняю: в Обероне начиная с 1990 года доступность процедуры извне модуля обозначается * возле ее имени.

Зачем гадать об отношении профессора, когда он сам о нем прямо сказал?

Что до моего мнения о таком решении, то я считаю что решение мягко говоря спорное, спровоцировавшее явистов (а вслед за ними и других) на безобразия. А оправдание этого решения тем, что мол можно интерфейс модуля автоматически сгенерировать спровоцировало на затыкание любых дыр в языке костылями из IDE.

alex55555,
а я то думал вы мне тут покажете класс понимания ООП и знания языка Java, утрете нос, и что мы пообсуждаем минусы и плюсы разных решений.

По решению задачи скажу кратко.

Генерируемый в отдельном визуальным редактором класс:


В xml описаны объекты с такими же именами.

В окне активите пишутся вручную две строчки



MyCoolLib.InitLayoutImp заполняет button1 и edit1 используя RTTI (Class). Реализацию прикиньте сами. Если не сможете - просите, напишу.
Дальше везде можно использовать L1.button1 и т. п. Гибкость сохраняется. Вполне удобно.

С методами все гораздо хуже. Кстати, почему то магистры андроида не вспомнили атрибут android:onClick . Пользоваться им неудобно, так как приходится редактировать в двух местах. Если бы можно было бы из редактора создать тело метода и сразу туда перейти - было бы удобно. А так нет. К тому же необходимость объявления обработчика public нарушает лелеемую инкапсуляцию.

Можно так же генерировать обработчик события в теле InitLayoutImp, но он тогда не сможет обращаться к Activity. Можно добавить в InitLayoutImp поле parent: Activity, но тогда придется приводить тип к Activity1 принудительно для обращения к специфическим методам, да и как быть, если вызывается из другой Activity - цепочку if-в устраивать? Уродливо. Тут больше всего мешает архитектурное решение не связывать layout с activity жестко. Так что это решение с обработчиками событий не дает почти ничего полезного по сравнению с их обычной инициализацией вручную.

Я не знаю, что вы понимаете под процедурным типом и свойствами.

"Указатель на функцию, указатель на метод класса" - так понятнее? Только в отличие от указателя процедурному типу нельзя ни численные значения адресов присваивать, ни нетипизированные указатели. Решили от хакерства таким путем защитится. Вдруг бы программист как то умудрился обойти ограничения и записал бы ссылку на вредоносный код и таким образом выполнил бы его?
Мотив понятен, а все равно неудобно писать эти монстроузные конструкции вместо простого присваивания обработчика.

Свойство это когда вы пишете что то вроде

property Width: integer read GetWidth write SetWidth

и потом используете Width везде как будто это просто поле (за исключением передачи параметра по ссылке).

androidannotations

Вообще не о том. Голимые макросы препроцессора. Недостатки макросов известны всем (кто не ява программист) 20 лет. В С они активно использовались, и были написаны тома критики.

butterknife

Еще один набор макросов. Со всеми их недостатками.

DataBinding

Это не то, о чем я говорил. Другая задача. Городят связь между визуальными компонентами и объектами данных. И весь код пишется вручную (плюс макросы). Вроде я четко условия задачи сформулировал. Можете их перечитать.

@BindingAdapter

И в нем голимые макросы препроцессора.

Но вы для меня новое открыли, действительно. И я не знал, что в Android-е макросы препроцессора так широко используются. Кстати, как они там называются, наверняка ведь придумали какой то свой термин?

Вот уж действительно все в этом андроиде изобретается заново из-за невежества, причем наступают на все грабли.

Можете сказать, что предложенный мной подход тоже генерирует код, хотя и из редактора. В чем принципиальное отличие от макроса, скажете вы. Но в моем случае код генерируется сразу в виде готового файла, его можно видеть и прочитать. А дальше все обрабатывается встроенными средствами языка.

Я понимаю, что тут читатели не догоняют. Сложно им понимать, когда у них умения делать магические настройки в IDE, а не умение абстрактно мыслить.

Не придирайтесь к неаккуратной работе с исключениями.

вызов



Предполагается, что это генерируется визуальным редактором и сохраняется в отдельный файл:



Придется обязательно указывать у верхнего layout id, т. к. у activity нет findViewWithTag и я не нашел за 10 минут способа получения текущего layout из activity. Может статься его и нет, чтобы не меняли состав контролов в произвольное время - запрет из соображений "оптимизации".

Аннотациями макросы обозвали. И используют на каждом шагу. Без @override ни шагу ступить.

@override - тоже макрос. Интересно, как он реализован.

Еще и расширили их применение в 8-й версии.

Скажите после этого, что Ява самодостаточный язык..

Без руля и ветрил несет Java неведомо куда, т. к. скопировав в начале работу мэтра (попоротив ее при этом), дальше его создатели уже не понимают, что делают и зачем.
Что уж там говорить об андроидных "программистах".

Как привлекательно использовать макросы - это же можно свой метаязык создать. Потом это приводит к хаосу. Но дилетанты об этом не знают, читать и понимать прочитанное не умеют, чужой опыт усвоить не в состоянии.

alex55555,

Просто взглянув на его первый "шедевр" в виде кода, можно набрать сразу с десяток косяков

Ну так давай, косяки в студию. Конкретно, что не так. Пока что от тебя только общие шаблонные фразы без доказательств.

Я бы даже рекомендовал его бред для начинающих - найди десять ошибок,

Ну так давай, найди. Перечисли. Именно десять. Жду.
Что ты ни своего ничего предложить не можешь, ни на ошибки указать.

chpasha
я тебе пытался объяснить, почему использование визуального редактора бесполезно, но ты либо не захотел, либо не смог понять. Еще раз - layout не принадлежит Activity эксклюзивно. Куча других сущностей может быть "связана" с layout, потому просто не существует одного такого места, где можно сгенерить что-либо. задача бессмысленна изначально.


Это ты теперь мои же слова, которые я давно сказал, мне же и повторяешь и преподносишь это как свое откровение о котором я не знаю. Похоже тебе действительно нужна помощь специалиста.

Давай, еще почитай, может до тебя дойдет, что в моем подходе как раз обеспечивается возможность гибкой связи разных Activity с одним layout.

Но похоже, тебе говорить что то бесполезно, т. к. ты вообще не программист и не понимаешь НИЧЕГО.

Я бы на месте Java программистов серьезно обеспокоился, что их всех начнут считать такими как chpasha . Который все, что ни говорит, все мимо, а в конце вообще начал мне мои же рассуждения пересказывать (о хамстве уж я и не говорю) и меня в них же и убеждать. Т. е. гражданин в принципе не способен воспринимать информацию.

Я бы на месте Java-программистов сказал бы такому - к ноге мол, кыш, не позорь нас, мы не такие. Извините, мол, не принимайте этого гражданина за нашего представителя.

chpasha,

просто набери в гугле "activity get view" - первая же ссылка на stackoverflow

А ты загляни в то, что там написано. Тот метод, который использую я. А без указания id у верхнего layout - нет. Блин, кому я это говорю..

состав контролов можно менять в любое время. добавлять, убирать, прятать

Тогда глупо не давать ссылку на верхний View в явном виде. Но разработчики Андроида не дают. Шедевр архитектуры..

java annotation processing

Почувствуйте разницу между файлом исходного кода в простом виде в каталоге проекта, который сразу видно и тем, что где то там генериться в нечитаемом виде.. Опять же, кому я это говорю..