обращение к полям класса

$attr

$ == SELF

Только this, только стандарт! Нет ничего ужасней и нелепей, чем выдумывание своих ключевых слов, когда во многих языках они уже в ходу. Пример тому — апплосвифт. Тонны переименованных кейвордов. Зачем? Непонятно. Но ужасно тошнотворно.

только стандарт!

Какой стандарт?

Чистого разума. Зачем мне помнить 10 обозначений одного и того же в 10 разных языках?

В случае с локальным/глобальным скоупом есть возможность статически отследить откуда переменная пришла. Атрибут может прийти откуда угодно. Плюс что делать с __getattr__? Например ты наследуешься от прокси. С динамической типизацией опускание this это боль.

Он и так без магии, совершенно тупой. В питоне даже перегрузить можно.

В питоне оно с магией, slots, превращает символ (хз как правильно назвать) в строку.

НИкакой магии, просто способ перегрузки. Гораздо гибче чем в плюсах.

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

Или у тебя динамическая типизация?

Статическая.

В питоне оно с магией, slots

Слоты сделаны через перегрузку __getattr__.

Зачем мне помнить 10 обозначений одного и того же в 10 разных языках?

Пойдём дальше, зачем вообще нужны 10 ЯП? Даёшь один стандартный!

замени self на this

Как ни странно, уже так и сделал ибо текущий интерпретатор написан на питоне и self уже зарезервирован.

пойдем еще дальше, зачем нужен твой, 11ый?

Вот скажем неск лет назад для разборщика командной строки повесил справку на ?, расширенную справку на ?+.

Примеры не равноценны. Для CLI-интерфейса лучше придерживаться стандартов чтобы юзеров не пугать. Чем меньше нового учить тем лучше. Да и профит небольшой.

ЯП же используют специально обученные люди (в идеале). Тут важно не только «удобство вхождения», но и последующего использования.

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

зачем нужен твой, 11ый?

«А мне интересно» (c) один из создателей атомной бомбы?

разница между классом и объектом рассматривается?

slots возникли для компенсации кривости реализации питоновского интерпретатора и проблем с памятью, из неё вытекающих

«кривость реализации» и «проблемы с памятью» это субъективная оценка. То же самое можно сказать про многие _динамические_ ЯП (потому что hashmap это удобный стандартный подход), но это не информативно.

Если у тебя есть более оптимальный способ представления для динамического объекта (когда можно добавлять и удалять поля на лету) то попрошу его в студию.

разница между классом и объектом рассматривается?

Хороший вопрос. Допустим что да. Текущая модель ООП такая: объект есть структура данных с набором функций (методов) для работы над этой структурой. Класс сам по себе просто набор методов. Класс так же является типом.

Наилучшее решение, которое я видел — это Io. Там контекст зависит от определения, block — лексическое связывание, method — динамическое.

На сколько это удобно и читаемо на практике? Я на Io никогда не писал.

Если разница есть, то значит актуальны как минимум два вида доступа к полям: статический и как угодно назвать доступ на уровне экземпляра (инстанции объекта)

Эта проблема во многих языках решается с разной степенью кривости. Используются различные уловки, хитрости. Например в JS нет явной статики, окромя имен. Вместо типа, прототипы.

В питоне (не скажу что он не нравится, скорее наоборот) странное слегка понятие статики и экземпляра объекта.

self.

Но он всегда был квалификатором статического контекста. Такие же странности в питоне с определением типа мне кажется.

Вообще, где интерпретируемые языки - там странности с типами и разницей между объектом и классом.

Хм, интересно. Так как ЯП типизированный то нет проблем понять к какой переменной идёт обращение. На практике мне бы хотелось иметь понятие «квалификатор доступа» (или как это зовётся) которое бы регулировало scope. Например, вот так:

somevar                 # обычная локальная переменная
.somevar                # атрибут объекта
$somevar или ::somevar  # атрибут класса

Т.е. подход как в CPP/Java где это разруливается неявно самим компилятором мне не нравится. Но я никогда (кроме как для «ардуино») на крестах не писал. На сколько подход cpp удобен/неудобен? cast tailgunner

Сразу скажу что я против квалификаторов типа как в perl (ну, всякие $/#/@).

В 3.3 оптимизировали потребление памяти для словарей:

Dictionaries used for the storage of objects’ attributes are now able to share part of their internal storage between each other

https://docs.python.org/3/whatsnew/3.3.html

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

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

Ну тут стоит вопрос «скорость написания vs скорость исполнения». Ты же не пишешь шелл-скрипты на сях. Ну просто потому что это очень неудобно и лишено смысла.

Чтобы выбрали ты

Просто some.attr.

А вот интересно, если бы компилятор умел держать контекст (без подсказок, как в естественных языках), увеличилось бы количество ошибок в программах? Упростилось бы написание? Пытался ли кто-то так делать?

  smth.a = 10;
  a = a * 2; /* smth.a *= 2; */

По-моему, ты смешиваешь доступ к атрибуту объекта с доступом к имени в области видимости. В Си++ класс сделали областью видимости и, как по мне, это сомнительное решение - класс должен быть объектом и иметь атрибуты, а области видимости имен должны регулироваться модулями (пакетами, крейтами) и блоками. Возможность иметь локальные переменные, совпадающие по именам с членами объекта (да даже и глобальными переменными) - бессмысленная и даже слегка вредная гибкость, опять же по моему мнению, а при ее отсутствии весь доступ к областям видимости делается через систему модулей. А красивости вроде @attr (если они нужны) можно обеспечивать тупо поверх наличия аргумента вроде self - «имена вида @attr, обнаруженные в методах класса, рассахариваются в доступ к атрибуту attr первого аргумента метода».

Пытался ли кто-то так делать?

Смутно припоминаю, что да - в каком-то языке 60-70-х.

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

quadruple_epic_facepalm.4k.mkv

Естественно, это удобно и читаемо на практике, поскольку позволяет не забивать голову лишними синтаксическими конструкциями — паразитами.

Упростилось бы написание? Пытался ли кто-то так делать?

with-statement в pascal? http://www.freepascal.org/docs-html/ref/refsu58.html

Я, кстати, подумываю об этом :)

.somevar # атрибут объекта

$somevar или ::somevar # атрибут класса

Зачем это нужно? если надо различать, можно что-то вроде функции object.hasOwnSlot. Можно сделать опциональный сахар, но в общем случае, это лишнее усложнение.

with-statement

Это же с подсказкой. Интересно когда железка сама пытается додуматься

Интересно когда железка сама пытается додуматься

Для твоего примера это реализуется легко, но мне, честно говоря, идея совершенно не нравится.

вот пример на JS

a=1
;(function(){console.log(a)}).call({a: 10})

как ты без явного указания свяжешь a? Ты просто лишишь себя гибкости. Явное указание контекста нужно, хотя бы опциональное. в достаточно гибких языках, помимо лексического и динамического контекста, есть явные указания на контекст класса, предков, вызывающего кода, и тд. То что по дефолту что-то разруливается не отменяет того, что часто удобней обращаться явно. Это, по сути, основной критерий гибкости.

Очень зыбкая грань. Скажем тем что я делаю пользуются только специально обученные люди, хоть и через CLI. С другой стороны на VB/шарпах/питоне кто только не пишет...

Интересно когда железка сама пытается додуматься

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

Сделай оба варианта, чего тут думать то.

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

Разработчики руби давным давно уже все придумали.

class Class
	def self.field
		"field"
	end
 
	def self.method
		puts field
	end
end
 
Class.method 

В случае с локальным/глобальным скоупом есть возможность статически отследить откуда переменная пришла. Атрибут может прийти откуда угодно. Плюс что делать с __getattr__? Например ты наследуешься от прокси. С динамической типизацией опускание this это боль.

Здесь вся прроблема только в локальном пр-ве имен, т.е. для поиска простого имени сначала нужно было бы заглянуть в локальную область и затем в this. Локальное пр-во тоже динамическое (это, кстати, тоже большой косяк питона, ненужный гемор на ровном месте), т.е. статически тут ничего отследить не получится.

Всяко лучше придумать костыль для локального обращения чем обращаться к this через self. Например, в питонячем стиле можно было бы считать символы начинающиеся с «_» обращением к локальному пр-ву.