0xd34df00d
14.08.2012 17:59 Azoth_primary
QTabBar *NavBar_;
QListWidget *NavButtons_;
Оба класса наследуются от QWidget.
QWidget *widget = useTabs ? NavBar_ : NavButtons_;
Хуй там.
128 comments
recommend
bookmark
subscribe
qobject_cast?
Тут и статик-каста хватит, ибо апкаст по иерархии.
и? апкаст сделать западло?
Да.
а какого хуя тогда не auto widget = ... написано?
Изначально так и было написано, но я вспомнил, что ты бугуртишь от этого.
Да и сути это не меняет.
напиши плугин к гоцацэ, который будет уметь разруливать подобные ситуации. ты ведь любишь плагины
Плохой язык. Баш лучше, в нём нет таких пробем.
Нет типов — нет проблем, да.
Тип есть!
Есть красивое решение
QWidget *widget = useTabs ? NavBar_ : true ? NavButtons_ : widget;
интересно, какого поведения ты ожидаешь, если у двух классов найдётся два общих предка в разных линиях наследования
И даже тут система типов плюсов соснула, как ты видишь.
Не, это пиздец какой-то.
пока я вижу только как ты соснул.
> плугин к гоцацэ
А ты добрый.
> нет типов
какое распространённое заблуждение о динамической типизации!
>>> x = 42
>>> x()
Traceback (most recent call last):
File "<console>", line 1, in <module>
TypeError: 'int' object is not callable
> TypeError
> Type
> Error
> Type
о чём ты вообще? тут про питон или динамическую типизацию никто и не вспоминал.
нет, вспоминали, /8, /9.
Говорили о статической типизации. Причем тут питон с его динамическим кококо?
покажи какое там слово говорит о питоне или динамической типизации. а в sh таки никакой типизации нет, там все переменные содержат строки.
по-моему ты просто слишком озабочен питоном...
ох не пизди, в нормальных (юзабельных) шеллах есть даже асоциативные массивы
у меня просто ещё не высохли волосы и мне скучно
ну тогда шеллом почти что угодно обозвать можно :3 в /8 таки говорится о bash, но я без понятия что там из типов данных есть (да-да, я сраный неосилятор)
> Плохой язык. Баш лучше, в нём нет таких пробем.
при том, что статикобляди ВНЕЗАПНО соснули у динамикобогов :cf:
ты хуй.
ну вот в баше асоциативные (и обычные) массивы и есть. Так что не пизди мне тут про строки.
Вот в тикле — да, строки.
Ты упорот.
на следующую днюху тебе надо подарить чай для похудения.
ты
Питон для поблядения.
поздно, DOEN by @jtootf
тоже DOEN, лол.
в sh таки строки, а про bash я уже сознался что не знаю.
fuck
ничего, твой подарок тоже охуенный :3
Это не ошибка типизации, это в рантайме выкинутое исключение, волею судьбы названное TypeError. Ты тоже можешь выкинуть его где угодно, но типизацией у меня это язык не поворачивается называть.
но чая подаренного @jtootf'ом тебе явно оказалось мало
wait a minute. С философией названий мы можем далеко зайти.
Ты отрицаешь, что там в рантайме есть типы?
В этом вашем петушоне же в рантайме можно добавлять-удалять методы какие-нибудь, да?
хуй с ними, с методами. они поля добавляют-удаляют на лету
Кококо.
да, можно. «Тип» при этом меняется просто :cf:
Вроде эдакий каст, но только не ради тайпчекера, а по делу.
если честно, я себе достаточно давно ломаю голову над тем, что же такое "типы в рантайме". то есть это ведь совершенно не то, чем типы являются в философском (ну ок, моем интуитивном) понимании, а это лишь "метка", которая навешивается на данное, и рантаймом же проверяется всё, что он захочет. эдакий type-tags обыкновенный. но это ведь (type-tags) скорее о динамической диспетчеризации, а не о типизации в привычном мне виде.
можно в цикле метаклассы создавать. ну и хуй?
SURPRISE! при статической типизации это тоже просто метка для кучки байтиков, только её ещё компилятор проверяет.
всё так. иногда это стреляет в ногу, иногда помогает.
собственно, для меня разница в том, что не только "компилятор проверяет", но и "можно строить рассуждения о корректности программы, и операций над типами (их слияние, поглощение, объединение и прочая хуйня)". понимаешь?
собственно, никто не мешает делать то же самое и при динамической типизации, только это сложнее
Хуита.
Не хуита, нормик сказал.
Так рано или поздно все равно все — типизация, ибо что-нибудь да проверит. Херовый дефинишен.
Мешает halting problem.
что ты несёшь
Питонобляди не понять. Напиши еще один декоратор да сосни гвидца.
а при статической типизации не мешает, да?
покукарекай мне тут
да он просто со знающим видом спизданул крутой термин, хвост распустил и расхаживает.
Система типов языка не обязана быть тьюринг-полным языком.
Поумерь свой бугурт уже.
а при чём здесь динамическая/статическая типизация?
лолда, система типов должна ограничивать программиста так, чтобы время на написание кода / тайпчекинг разделялось ПРИМЕРНО ПОРОВНУ
поумерь чсв
Хотя, впрочем, иногда бывает. Отсюда получаем темплейты в плюсах и счастье с ними, отсюда же довольно тривиальные факапы в System F и и ей подобных, которые решаются усилением системы типов и усложнением тайпчекера, но далеко не все.
Зато можно численно интегрировать на тайпчекере.
всё, пиздец, я не могу это читать.
Мы говорили про статический анализ кода для проверки корректности программы, нет?
Или как ты предлагаешь доказывать корректность программы с такой-то динамической типизацией, кроме КОКОКО ПРИШЛО ВРЕМЯ НАПИСАТЬ ЕЩЕ ТЕСТОВ?
БУГУРТ ГЛАЗА ЗАСТЛАЛ
Еще один все понял
!
хватит уже под статическим анализом подразумевать исключительно проверку типов. Есть ещё data flow analysis, есть символическое исполнение и прочее.
саси
Расскажи мне про символическое исполнение.
И я не подразумеваю исключительно проверку типов. Просто без нее никуда. Ты опять путаешь необходимое и достаточное?
> проверку типов. Просто без нее никуда.
олололоол, а мне было уже показалось, что ты наконец спустился до содержательной дискуссии.
> без нее никуда.
как насчёт тикля или js?
А што насчет них? Они оба говно. Вон, не зря в dart водят что-то статикоподобное, и в v8 пытаются выводить метки во время этакой конпеляции.
алсо, почитай что-нибудь о внутренностях PyPy, мне ехать надо
то, что они говно — не принципиально. Главное, что мы оба о них знаем, и что в них практически нет проверок типов, без которых «никуда».
Да ты же и так уже ПОЕХАВШИЙ.
Блядь, я говорил, что для статического анализа без проверок типов никуда, нахуй ты там квантор всеобщности поставил?
объяснюсь на более конкретном примере: в статической типизации тип — это не только тег для диспетчеризации, но и набор методов и свойств (возможно он им не является, но всегда при статической типизации имеются проверки компилятора о доступе к несуществующему полю и т.п.).
то есть, при статической типизации — взятие отсутствующего свойства у объекта (или вызов несуществующего метода) — это ошибка типизации, в то время, как в динамическом ЯП взятие свойства у объекта — точно такая же динамическая функция, которая может выкинуть TypeError, может не выкинуть и вообще как захочет так себя и ведёт. то есть по сути можно сказать, что тип никак не несёт в себе информацию о полях/свойствах. на этом моменте у меня голова и ломается, мол, и там типизация, и там типизация, но в реальности понимаешь, что в динамических ЯП она попросту отсутствует (ну, точнее присутствует только в качестве type tags).
а про halting problem — да, хуйню дедфуд какую-то несёт, но аналогию унюхать можно.
> И я не подразумеваю исключительно проверку типов. Просто без нее никуда. Ты опять путаешь необходимое и достаточное?
а вот это — полная хуйня. про "КОКОКО БЕЗ ПРОВЕРКИ ТИПОВ НИКУДА". просто нужно понимать, что иногда типы скорее мешают, нежели помогают. и иметь дешёвую возможность на время теста подменить вызов методов с сайд-эффектами, или же у объекта сделать хитрый __get__ иногда очень даже клёво.
не понял, при чем здесь?
извольте, уж лучше лисп и макросы.
но вообще, если смотреть на объект как на функцию, замыкающую внутри себя состояние (и возвращающую функцию-диспетчер сообщений) — уверен, что дальнейший вызов define внутри неё считался бы крайне плохим тоном (в отличии от set! (присвоения)) и даже сложен для прочтения / восприятия, в то время как в ООП, присутствующем во всяких там питонах, в которых в инициализаторе ты делаешь self.foo = 'bar', наоборот как бы подталкивает "ну давай, добавь потом еще чего-нибудь в рантайме". ну а в купе с питоновской привычкой (большинства ORM) хитро запихивать всё в статические дескрипторы (о которых мало кто знает, и которые уже дальше работают с self'ом, но простой программист Вася этого не видит, потому потом еще и городит туда же статические переменные, которые предназначались быть прибинджены к объекту, а не классу)
что-то вроде:
class Person(Model):
name = StringField()
foo = '' # ← а надо было в __init__ сделать self.foo = ''
короче я давно уже считаю, что в питоне надо было этот синтаксис оставить для self.foo-свойств всяких там, а для членов класса придумать что-то иное. тогда бы докидывали атрибуты вообще крайне редко.
Я сейчас думал, как бы поехидней на это ответить и внезапно грокнул CLOS. Спасибо.
там статический анализ питонокода. Говорят, оче хороший, во всяких частных случаях догоняет сишечку.
там нет никакого питона, это RPython, который является его сильно подмножеством. или ты про jit-компиляцию вообще?
ну да, там RPython и всё такое, но он же делает неплохой такой whole program analysis. Скажем, счётчики в простых циклах превращает в нативные инты, и т.п.
чё? еще раз, счётчики в простых циклах превращает в нативные инты их tracing jit, при этом ни о каком статическом анализе речь не идёт. речь идёт об анализе интерпретатора (написанного на статически-типизированном ЯП RPython, затем транслирующимся в код на Си), при этом в местах, где эта самая переменная (int) может поменять тип (и вообще везде где нужно) аккуратно расставляются guard'ы, при недостижении которых все эти оптимизации посылаются нахуй и интерпретатор возвращается к старому доброму медленному интерпретатору. короче говоря это всё про jit'ы хуё-моё, но никак не про статическую типизацию. ну и whole program analysis там нету, там вообще program analysis происходит не по отношению к твоей питонопрограмме, а по отношению к интерпретатору, написанному на RPython'е.
аааа. епт. Tell me moar.
Хуита.
да я лох, лучше почитай сам их на readthedocs и на ютубе глянь.
Кстати, да. Stringly-typed можно писать хоть на х-ле.
ну канэшно. и иногда, наверное, даже нужно.
дедфудота.
кстати, Паша просил передать, что плюсы говно.
Паша — это Crazy Owl?
ожидаю диагностики CANNOT RESOLVE AMBIGUITY; и компилирующегося кода в случаях отсутствия неоднозначности, как в /0.
нет :3
Передай Паше, что он мог бы просто пройти мимо.
R.
Я про то же уже писал.
да сколько уже можно батхертить, дедфуд. Почему ты такой злопамятный?
Я не бугурчу, я просто пользуюсь его же логикой. Зачем передавать, что плюсы говно, когда можно просто пройти мимо?
ты именно что бугуртишь.
Зачем ты такой примитивный?
што
То.
> То.
кто примитивный — ты примитивный, епт.
я просто улиточка, мне можно :3
Ну у тебя кроме бугурта других эмоций нету просто, вот и примитивный. Да, хоть я и уважаю Пашу как программиста и музыкоёба, его позиция в отношении социальных интеракций мне не импонирует, и я ему лишний раз показываю ее абсурдность.
Схлопывать это со всеми оттенками в слово «баттхерт» — примитивно.
нет, только на этапе компиляции
АБСТРАКТНЫЕ БАЗОВЫЕ МЕТАКЛАССЫ
например. а можно вообще отрендерить темплейт, а потом скомпилировать и выполнить.
а в питоне вообще никто ничего не проверяет и всем норм
ты забыл про БУЛЬОН^W%another_programming_cool_buzzword_here%
нихуя, есть :3
цитата_из_матрицы.тхт
> бульон
> buzzword
што.
которая именно?
он не скажет, слишком илитарий
которая более всех сюда подходит
ну хотя бы кто сказал?
слишком гельминтарий
ЧЕРВЬ
ЧРЕВ
ВЕЧР
человек за компьютером
Чiрвь!
Хробак!
алсо, у тебя плохая, неправильная і.