Для начала вам придётся увязать нечто из этих лекций с тем, что тут. Понимаете, что мне не нравится и вашем посте также — ссылки на какую-то сакральную информацию. Информацию нужно уметь презентовать, увзязывая с интересом слушателей. Иначе это баг мышления.
Тут ньюанс в пункте 8 статьи. Представляете, как выглядит текст такой программы? Он совершенно не похож на то, что в Delphi и Java и в C++. Он — что-то типа Лиспа, очень малое соотношение числа строчек кода к числу типов. Фактически, нижнему по иерархии классу чаще всего придётся работать с единственным полем. Поскольку, класс-метод, который уже что-то делает вразумительное, скорее всего будет внешним. В таком случае, разве, одних внутренних же методов не достаточно (без своих полей вовсе)?
Может быть, есть смысл как-то дополнительно информировать пользователей класса о чём-то?
На самом деле, так получилось, что я property использовал 15-20 лет назад в Delphi и мне сразу показалось, что в изложенной мной модели это обыгрывается всё тем же внутренним методом, поскольку внутри этого маленького «метода-класса» все филды — private. Что может быть проще? Так или не так?
Поскольку, за основу я взял труп Java и final не убирал, то, в итоге, объявить final «класс-поле» и филд внутри, примитивный или опять ссылку — не проблема.
Перегружать синтаксис присваивания мне кажется неуместным тут. Это всё же методы, а внутри них — всё же настоящие присваивания своим филдам.
Просто, ваше замечание по существу было одно и первых и в такой категоричной форме, что хотелось услышать расширенный комментарий в контексте обсуждаемой темы, а не в контексте Java или Delphi. Потому что property есть не только в Delphi, да и Delphi за много лет мог поменяться, и вообще, мало ли кто и что может придумать.
В принципе, работа программиста и состоит в том, чтобы что-то чему-то объяснять, особенно сложно это делать тупому компилятору. Таки вы этого умения почему-то не демонстрируете, всё остальное — лирика. Докажите мне, что я тупее компилятора. У вас это не получится никогда, зато, я знаю ваши проблемы как свои пять пальцев и они тоже социально-лингвистические, если хотите.
Какая разница, какой информацией вы владеете или не владеете, если вы всё равно не умеете с ней работать. Даже, если, предположим, лично вы и умеете это в другой ситуации, то общей удручающей картины это не отменяет. Как вообще люди умудряются со всем этим психологическо-социальным грузом создавать сложные системы, которые в принципе, по факту самой своей сложности, склонны порождать новую и ситуативную семантику? Вот это и есть тот самый главный баг.
По вашей ссылке написано ровно то, о чём я написал сообщением назад. В остальном, причём здесь синтаксис Делфи? Как это будет с точки зрения процессора, виртуальной машины? От простой мысли, что, скорее всего, в изложенной мною модели это избыточно и неудобно, вы прячетесь как чёрт от ладана, хотя уже можно было формализовать всё, что угодно. Чувак за время нашего с вами общения уже написал двадцатую часть javaScript, а мы топчемся на месте. Так работать нельзя. Не хочу я работать так. Ни с кем, и хорошо, что я с вами ещё не работаю, а жаль, что придётся — если не с вами, то с кем-то таким же, придётся вас гипнозом менять. Вы поддаётесь гипнозу? Что на вас действует? Жёлтые штаны?
Всё же в Delphi property присущи только классу, а не подпрограммам. Мне же хотелось как раз уйти от такой объектной модели. Property наверное очень полезны, но вот как будто абсолютно очевидно, что внутри очень маленьких классов они абсолютно излишни. Кто знает, кто знает
Кстати, khim, вы не ответили ниже по существу и не одному мне, там какие-то properties. Вообще, работа мозга это очень и очень занятная штука, а ещё занятней — работа системы мозгов да ещё и в связке с нервными системами. Не даром устройство нейрона до сих пор никому не известно. В средние века в первом классе школьники своё образование начинали с «тривиума» — логика, риторика, грамматика. У нас первые два куда-то перенеслись настолько на очень никогда потом, что умереть со смеху. Представляете, вы на энном курсе института вскользь прошли бы арифметику. Аккурат после матанализа. Нормально? Вот и мне смешно.
Весь этот мерзкий тривиум на самом деле пошёл от чудака Сократа, который очень хорошо понимал то, что ничего не понимает. Такое не каждому дано. Т.е., «ничего не понимает» это комплимент и ещё какой. После Сократа жила старушка Грейс Хоппер, автор Кобола, одной из целей которой было максимально приблизить конструкции Кобола английскому языку, и ещё в 2006 году Кобол считался языком программирования, на котором было написано больше всего строк кода — из Википедии. Двуногим же без перьев типа меня обычно и приходится юзать всё такое гениальное, а вдруг и правда гениальное — я же не спорю. JavaScript был там кем-то из нетскейп что ли написан за десять дней чтобы только не визжал бейсик. И опять чувак попал в струю. Очевидно, я так не умею, но мне приходится с этим иметь дело.
Тоже считаю, что очевидный прогресс велосипедной техники невозможен без изобретений. Вкладывайтесь, я освою. Вообще, сторонние фреймворки хороши до определённого момента, после они очевидно тормозят развитие, но от них уже не отказаться. Любой большой проект уже содержит в себе новую семантику и свой фреймворк, иначе ему не стать большим, либо стать большим за нереальные деньги, видел я такой — собирается сутки. Тысяча кодеров по чуть-чуть копаются в меркуриале. Сколько это всё стоит мне страшно себе представить. Красота природы в том, что мне после этого проекта достался по наследству визуально очень похожий и по схожей тематике, но по началу я кодил его… один бедняжка. Т.е., по множеству функций, которые юзер дёргал, с первого взгляда он был не намного проще того гигантского. Конечно, это только с первого взгляда, но я был в начале и в конце лавины и это впечатляет. Технологии и в первом и во втором практически идентичные. Ява это очень солидный язык.
Что же до дефолных значений, то и 0 денег по дефолту никого не обидит, если код вдруг начнёт кодить бывший гений после автокатастрофы. Тем более что в Яве int как назло неявно ноль по дефолту, я же как раз предлагаю уйти от этого неочевидного но вероятного — как раз задать явно этот нужный банку NPException по дефолту, архитектор-то у проекта был до автокатастрофы. В остальной куче проектов, в 99%, в которых просто зайчик на экран не успел подпрыгнуть и от того null, все эти важности совершенно ни к чему, они сильно тормозят и отнимают время. Даже для банков такая щепетильность не везде хороша. Видел я эти бесконечные
Exceptions по любому поводу в Грузинских банкоматах.
Т.е, как, всё-таки, это может уживаться с работой изнутри родного класса? Тут по существу вложенные методы просто, очень маленькие классы. Проперти у меня из памяти конечно выветрились, но большие такие классы Делфи я помню, поскольку даже Паскаль не мой первый язык. Там обычно, да и в Яве сейчас очень и очень часто, такая большая сарделька которая понятно как образовалась — люди ночами не спали домой убежать мечтали а их тимлид не пускал. В таких условиях польза от пропертей очевидна, я в таких классах даже локальные копии всегда в методе устраиваю, чтобы потом слить всё что надо, а тут я попытался уйти от этой истории. Тут куча мелких вложенных классов как в Лиспе что ли.
Да я вообще маньяк порассуждать, я просто не могу строчить чаще чем раз в пять минут, а скоро меня заминусуют непонятно за что непонятно кто и раз в час только смогу:) Я правда вот так думаю, как там написал. Конструкции что-то диагностирующие наверное гуд, но сеттеров то они не отменяют, пока я не вижу способов как properties могут отменить сеттеры. Кроме того, я, зная себя, буду в сеттерах дублировать все проверки, если сеттеры понадобятся для чего-то ещё, такой я тормоз. Вообще, сильная стороны Java в том, что она для тормозов. Даже тысяча тормозов могут за очень много денег поддерживать очень тормознутый проект, и это реальная сила потому что многие компании имеют деньги, но не имеют гениев в своём штате. Революция устроил не я, а интервьювер, которому мне всё это в черновом варианте на английском пришлось строчить. Вот и вошёл во вкус.
Т.е, главный вопрос, который мне неясен. Как большое количество проверок может уживаться с работой с полем изнутри родного класса? В сеттере-то много всего, не будешь же это всё каждый раз проверять, особенно если у тебя по существу вложенные методы просто, а не большие объекты со словарями полей
В методе который дёргается снаружи можно проверять всё что угодно и делать всё что угодно вплоть до логирования. Внутри класса, если класс маленький, нужен прямой доступ к переменной, а если класс большой, то лучше запасаться консервами в ожидании ядерной зимы. Не так?
Мне нравится однозначность в языках, это когда то, что ты видишь, то и делается. А не как в Си++ в котором можно перегрузить вообще всё так что не поймёшь на каком языке написано. Это перебор. Когда сеттер это сеттер, то после любого копипаста никаких скрытых синтаксических изменений не будет. Что если я из внешнего класса скопирую во внутренний это присвоение, которое раньше было сеттером, и наоборот. Это очень неудобно с моей точки зрения.
В каком будущем, это о чём? В Яве сейчас есть. Каким образом стало «obj.hours = 25 или obj.hours = -12»? И каким образом бизнес логика, явно заданная вот этим вот сеттером, может быть нарушена, если null будет иметь дефолтное значение? С моей точки зрения, если часы обнулятся по дефолту, то это лучше всего остального. Так ведут себя любые часы.
По поводу первого — так я и не спорю, мне сеттеры и проверки на null очень даже нравятся когда такие проверки нужны.
Не понимаю, народу не нравится вулканизм, черти, ладан или философские обсуждения программирования считаете бессмысенными? Сказал же: Ява ни при чём. Мне казалось, это и так понятно было.
У меня была мысль, что поля можно модифицировать и читать напрямую из родного класса, благо классы должны получаться малюсенькими, т.е. синтаксис присваивания уже занят и, если его использовать, то уже надо что-то придумывать для родного сеттера и геттера. Кроме того, у мне была мысль, что все поля private, т.е. в наследниках доступны только сеттеры и геттеры, а пишутся и читаются только свои. Поля с именами, идентичными таким же в предке, я бы не давал делать, это в Яве чего-то мешающая ерунда какая-то.
Да Ява тут вообще ни при чём, просто как модель какая-то, типа Си для той же Явы. В Яве мне нравится типизация, как-то не доводилось встречать такую же удобную в других языках.
Может быть, есть смысл как-то дополнительно информировать пользователей класса о чём-то?
Поскольку, за основу я взял труп Java и final не убирал, то, в итоге, объявить final «класс-поле» и филд внутри, примитивный или опять ссылку — не проблема.
Перегружать синтаксис присваивания мне кажется неуместным тут. Это всё же методы, а внутри них — всё же настоящие присваивания своим филдам.
Просто, ваше замечание по существу было одно и первых и в такой категоричной форме, что хотелось услышать расширенный комментарий в контексте обсуждаемой темы, а не в контексте Java или Delphi. Потому что property есть не только в Delphi, да и Delphi за много лет мог поменяться, и вообще, мало ли кто и что может придумать.
Весь этот мерзкий тривиум на самом деле пошёл от чудака Сократа, который очень хорошо понимал то, что ничего не понимает. Такое не каждому дано. Т.е., «ничего не понимает» это комплимент и ещё какой. После Сократа жила старушка Грейс Хоппер, автор Кобола, одной из целей которой было максимально приблизить конструкции Кобола английскому языку, и ещё в 2006 году Кобол считался языком программирования, на котором было написано больше всего строк кода — из Википедии. Двуногим же без перьев типа меня обычно и приходится юзать всё такое гениальное, а вдруг и правда гениальное — я же не спорю. JavaScript был там кем-то из нетскейп что ли написан за десять дней чтобы только не визжал бейсик. И опять чувак попал в струю. Очевидно, я так не умею, но мне приходится с этим иметь дело.
Exceptions по любому поводу в Грузинских банкоматах.
Т.е, главный вопрос, который мне неясен. Как большое количество проверок может уживаться с работой с полем изнутри родного класса? В сеттере-то много всего, не будешь же это всё каждый раз проверять, особенно если у тебя по существу вложенные методы просто, а не большие объекты со словарями полей
По поводу первого — так я и не спорю, мне сеттеры и проверки на null очень даже нравятся когда такие проверки нужны.