в го тоже нет генериков, и не собираются добавлять даже)

Поэтому ты обычно грустный. :)

да аще тоска

в го тоже нет генериков, и не собираются добавлять даже)

у них хотя бы есть структурный тайпинг)

а у тебя нихера нет) phpdoc только

Propel все?

Вообще, там rfc висит, но голосования никакого нет вроде

Вообще, там rfc висит, но голосования никакого нет вроде

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

Я про то, что не понял, что влияет на принятие какого-то rfc

1. наличие имплементации 2. факт того что имплементация не наносит существенного вреда производительности (как это было с typed properties) 3. факт того что фича реально нужна и от нее будет существенная польза (то есть это не мелкий сахар усложняющий парсер и позволяющий тебе сэкономить пару символов). короч самая большая и сложная работа тут - убедить комьюнити что фича стоит того что бы ее потом поддерживали.

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

так а что за контора?) и сколько времени дали?

Ктонибудь работал с amphp? пытаюсь выполнить пример из доки

yield естесно должен быть в функции

а че в доке хуйня какаято?

или у меня

блин, написал вопрос и сам понял че надо

Loop::run(функция)

p.s. php, как и Си или Java - языки со слабой типизацией

Не существует стандартов слабой и сильной типизации, на которые мы можем однозначно ориентироваться. Поскольку эти слова - сравнительные понятия, то нам нужна точка отсчета, т.е. то, с чем мы сравниваем. Если кто-то говорит: "PHP - язык со слабой типизацией" и при этом не упоминает, по сравнению с каким языком PHP считается слабым, то он либо не понимает, о чем говорит, либо молчаливо подразумевает какие-то из языков (осознанно или не осознанно). Мы, люди, при общении всегда передаем неточную информацию и собеседнику остается предполагать, что имеется ввиду, полагаясь на свои знания, на контекст и т.д. Конечно передающий, может уточнять передаваемую информацию, тем самым сужая контекст, множество возможных выводов и облегчая собеседнику понимание. Но, опять же, контекстов может быть бесконечное множество, как и уточнение - понятие бесконечное. Стало быть, одно растяжимое понятие опирается на другое растяжимое понятие. Передача информации человеческим языком фактически не может быть абсолютно точной. Я это к чему? А к тому, что твое утверждение "php, как и Си или Java - языки со слабой типизацией" может быть понято разными людьми по разному и при этом все могут быть одновременно правы в своем выводе.

Не существует стандартов слабой и сильной типизации, на которые мы можем однозначно ориентироваться. Поскольку эти слова - сравнительные понятия, то нам нужна точка отсчета, т.е. то, с чем мы сравниваем. Если кто-то говорит: "PHP - язык со слабой типизацией" и при этом не упоминает, по сравнению с каким языком PHP считается слабым, то он либо не понимает, о чем говорит, либо молчаливо подразумевает какие-то из языков (осознанно или не осознанно). Мы, люди, при общении всегда передаем неточную информацию и собеседнику остается предполагать, что имеется ввиду, полагаясь на свои знания, на контекст и т.д. Конечно передающий, может уточнять передаваемую информацию, тем самым сужая контекст, множество возможных выводов и облегчая собеседнику понимание. Но, опять же, контекстов может быть бесконечное множество, как и уточнение - понятие бесконечное. Стало быть, одно растяжимое понятие опирается на другое растяжимое понятие. Передача информации человеческим языком фактически не может быть абсолютно точной. Я это к чему? А к тому, что твое утверждение "php, как и Си или Java - языки со слабой типизацией" может быть понято разными людьми по разному и при этом все могут быть одновременно правы в своем выводе.

это не сравнительные вещи. Это о том как ведет себя рантайм.

скажем в javascript любое выражение должно тебе что-то вернуть, вне зависимости от типов учавствующих в выражении. Потому язык со слабой системой типов. В Haskel или Typescript код который имеет выражение с несовместимыми типами тебе просто не скомпилится. Потому это язык с сильной системой типов. В Java у тебя есть тоже куча нюансов как себя рантайм ведет, а есть есть нюансы - система типов слабая. В C++ нюансов нет - тебе надо руками типы приводить на каждый чих - потому там сильная система типов.

это как явное vs неявное

Ну это твое понимание. Ты можешь сказать, что это не сравнительные вещи, а я скажу, что сравнительные. Почему ты должен быть прав? Я читал одни источники, ты другие. Стандартов нет, как я сказал. Один язык может быть с более сильной типизацией, чем другой. У PHP более слабая типизация, чем в C++ к примеру

Ну это твое понимание. Ты можешь сказать, что это не сравнительные вещи, а я скажу, что сравнительные. Почему ты должен быть прав? Я читал одни источники, ты другие. Стандартов нет, как я сказал. Один язык может быть с более сильной типизацией, чем другой. У PHP более слабая типизация, чем в C++ к примеру

https://en.wikipedia.org/wiki/Strong_and_weak_typing

я могу кинуть в тебя ссылкой на вики где все точки зрения разжеваны и на этом остановимся)

я могу кинуть в тебя ссылкой на вики где все точки зрения разжеваны и на этом остановимся)

Я тоже могу кинуть в тебя ссылкой, где сказано то, что сказал я https://de.wikipedia.org/wiki/Starke_Typisierung

Та же википедия, просто другой язык.

Я тоже могу кинуть в тебя ссылкой, где сказано то, что сказал я https://de.wikipedia.org/wiki/Starke_Typisierung

я не умею в немецкий а потому не могу прочитать

Переведи в гугле на английский этот абзац: Starke Typisierung wird meist mehr als Vergleich denn als absolute Bezeichnung genutzt: Sprache X ist stärker/strenger typisiert als Sprache Y. Bei solchen Vergleichen spielt sehr oft das Vorhandensein impliziter oder auch expliziter Konvertierungen eine Rolle; so ist PHP deshalb schwächer typisiert als C, weil PHP fast überall implizit konvertiert, C jedoch nur bei ähnlichen Typen. C++ ist wiederum deshalb stärker typisiert als C, da z. B. implizite Umwandlungen von void* in beliebige andere Zeiger nicht erlaubt sind. Noch stärker typisiert ist wiederum Object Pascal, das im Gegensatz zu C++ keine impliziten Konvertierungen zwischen Boolean- und Integer-Werten vornimmt. Und Haskell erlaubt noch nicht einmal implizite Konvertierungen von Ganz- in Gleitkommazahlen.

Не пойми как оскорбление. Просто гугл с немецкого на английский хорошо переводит

По крайней мере, лучше, чем на русский

Та же википедия, просто другой язык.

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

но если хочешь конкретики - сравни систему типов PHP и того же тайп скрипта, или идриса, или лиспа

и грусти

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

"Strong typing is usually used more as a comparison than an absolute denomination."

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

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

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

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

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

Нет, не говорил, но это не мешает тебе поспорить с ней)

....ты выдумываешь уже что-то

или ты про strict_types? я ж говорю, это кастыль который должен был помочь с плавным отказом от жанглирования типами в рантайме. А без жанглирования типами язык внезапно ставится с сильной системой типов)

....ты выдумываешь уже что-то

Выдумываю что?

Выдумываю что?

короч я потерял нить общения потому либо давай конкретику либо закругляемся

Конкретики нет, есть только уточнения, которые стремятся к бесконечности, о чем я и сказал в самом начале. Но если кратко, то мое утверждение: строгая и сильная типизация - понятия сравнительные.

Выдумываю что?

Ты как то слишком сложно хочешь донести мысль "все познается в сравнении" :)

Парни, есть какой-нибудь инструмент конвертации JSON Shema в человекопонятный вид? А то мне прислали схему на 1000 строк, не охота быть интерпретатором этого ЖСОНа

Ты как то слишком сложно хочешь донести мысль "все познается в сравнении" :)

Моя мысль касается большего, чем просто "все познается в сравнении"

Парни, есть какой-нибудь инструмент конвертации JSON Shema в человекопонятный вид? А то мне прислали схему на 1000 строк, не охота быть интерпретатором этого ЖСОНа

погуглил за тебя http://jlblcc.github.io/json-schema-viewer/

я уже доку ставлю

Моя мысль касается большего, чем просто "все познается в сравнении"

я понимаю о чем ты, но проще рассуждать о двух точках чем о "все что между ними". И в этом смысле есть явное и неявное которые тоже не абсолютные понятия.

ну и поскольку началось все с дженериков я все же не понимаю как мы перешли к этой дискуссии...

погуглил за тебя http://jlblcc.github.io/json-schema-viewer/

Неплохой прокси из тебя получился)

ну и поскольку началось все с дженериков я все же не понимаю как мы перешли к этой дискуссии...

Все началось с того, как я сказал, что необходимость в дженериках появилась из за существования строгой типизации. Они ведь созданы для того, чтобы применять одни и те же алгоритмы, к разным типам данных. То есть основная проблема решена. А остальные удобства, порождаемые дженериками - это побочный эффект. В php подобной проблемы нет, можно одни алгоритмы применять к разным типам данных (конечно с оговорками). Но один джентльмен выше утверждал, что php нужны дженерики, только лишь ради побочных эффектов. Стоит ли это того? Усложнять синтаксис, ради пары удобств? Не получим ли мы в итоге просто синтаксический сахар?

Все началось с того, как я сказал, что необходимость в дженериках появилась из за существования строгой типизации. Они ведь созданы для того, чтобы применять одни и те же алгоритмы, к разным типам данных. То есть основная проблема решена. А остальные удобства, порождаемые дженериками - это побочный эффект. В php подобной проблемы нет, можно одни алгоритмы применять к разным типам данных (конечно с оговорками). Но один джентльмен выше утверждал, что php нужны дженерики, только лишь ради побочных эффектов. Стоит ли это того? Усложнять синтаксис, ради пары удобств? Не получим ли мы в итоге просто синтаксический сахар?

не "строгой" а статической тогда

> В php подобной проблемы нет, можно одни алгоритмы применять к разным типам данных ценой того что у тебя отстутствует возможность в компайл тайме проверять типы

> В php подобной проблемы нет, можно одни алгоритмы применять к разным типам данных ценой того что у тебя отстутствует возможность в компайл тайме проверять типы

Ну это ж и суть php. Со статическими типами он станет другим языком. Хотя я не против

Ну это ж и суть php. Со статическими типами он станет другим языком. Хотя я не против

тогда нафига в php тайпхинтинг вообще?)

для рантайма, ваш КО)

тогда нафига в php тайпхинтинг вообще?)

Чтобы плавно перейти к статической типизации)

для рантайма, ваш КО)

тайпхинтинг рантайму в php нинужон

Чтобы плавно перейти к статической типизации)

статическая типизация без умного компилятора способного выводить типы - это скорее путь вникуда

есть тулинг, типа пхпшторма, которому очень даже полезны тайпхинты

и он тебе все проверит еще до того как ты запустишь)

ну и в целом, основная суть в ВОЗМОЖНОСТИ, опциональной возможности задавать типы. Именно по этому я в пример привел python

есть тулинг, типа пхпшторма, которому очень даже полезны тайпхинты

ты мне рассказываешь?)

Парни привет. Подскажите, в бандле может быть конфиг одной сущности в yml, а другой xml? Так получилось что один конфиг в xml, внес изменения в конфиг yml и при entities получаю No mapping file found named 'Tkd.orm.xml' for class 'BonusRgksBundle\Entity\Tkd' как обновить сущности и схему?

Именно потому, что тайпхинтинг опционален, проверка типов все равно будет происходить в рантайме

Именно потому, что тайпхинтинг опционален, проверка типов все равно будет происходить в рантайме

мне не нужна проверка типов в рантайме, мне в компайл тайме надо

проверка типов в рантайме это херня какая-то

мне не нужна проверка типов в рантайме, мне в компайл тайме надо

Я знаю, мне тоже

я это могу делать просто на assert-ах

мне вот эти обсуждения напоминают адептов ФП в котлин чате

они ходят и ноют что им нужен паттерн матчинг, HKT, и чтоб монадами можно было обмазаться

вместо того чтобы просто писать себе дальше на скале, они требуют эти фичи в другом языке

вот так и с пхп, вместо того чтобы просто сменить язык, все ходят и ноют о типизации)

Парни привет. Подскажите, в бандле может быть конфиг одной сущности в yml, а другой xml? Так получилось что один конфиг в xml, внес изменения в конфиг yml и при entities получаю No mapping file found named 'Tkd.orm.xml' for class 'BonusRgksBundle\Entity\Tkd' как обновить сущности и схему?

Насчет одного бандла не уверен. Думается мне, что нельзя в одном бандле иметь гибридные конфиги.

вот так и с пхп, вместо того чтобы просто сменить язык, все ходят и ноют о типизации)

Но нельзя же просто сменить PHP, на нем 80% сайтов всего мира написано. А это большой плюс, большее сообщество, больше проблем уже решено. Хочется, чтобы язык, который тебе нравится, стал еще лучше)

вот так и с пхп, вместо того чтобы просто сменить язык, все ходят и ноют о типизации)

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

Но нельзя же просто сменить PHP, на нем 80% сайтов всего мира написано. А это большой плюс, большее сообщество, больше проблем уже решено. Хочется, чтобы язык, который тебе нравится, стал еще лучше)

именно что "сайтов", для обычных сайтиков ваша типизация нафиг не нужна

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

добавлять фичи нужно очень аккуратно и обосновано, иначе язык перестанет быть гибким

Насчет одного бандла не уверен. Думается мне, что нельзя в одном бандле иметь гибридные конфиги.

похоже что нельзя, получается надо xml переписать в yml

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

кстати, в Hack(который пхп фейсбука) щас хотят корутины затащить, такие же как и в котлине

похоже что нельзя, получается надо xml переписать в yml

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

похоже что нельзя, получается надо xml переписать в yml

Именно из за этого я предпочитаю реже использовать бандлы, и писать самому. В пределах разумного конечно. Была как-то такая связка: Symfony 2.8, SonataAdminBundle, FOSUserBundle и еще какие-то. Все конфигурации были разбросаны по проекту в разных форматах и файлах, некоторые локализации в XLIFF формате, некоторые в yaml, некоторые роутинги в xml, некоторые в yaml, некоторые через аннотации. Такое же дерьмо и с сервисами. Это был ад просто.

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

случайно так получилось, я и оставил, вот теперь геморой

кстати, в Hack(который пхп фейсбука) щас хотят корутины затащить, такие же как и в котлине

осталось чтоб симфу под хак заточили )

и можно ехать

симфа уже отьехала от хака)

а раньше поддерживали совместимость

осталось чтоб симфу под хак заточили )

Скорее наоборот

а так бы можно было говорить что это новый пхп у нас )

и потихоньку сваливать

интересно почему они не вложились в развитие пхп а свой хак стали делать

интересно почему они не вложились в развитие пхп а свой хак стали делать

что считать не вложились.... php если что коммерческий продукт, та же Сара Гольдман весьма активный член PHP интерналс, менеджила релиз то-ли 7.2 то-ли 7.1

ну то есть, они то вкладывались, но php пошел своей дорогой...

>php если что коммерческий продукт А можно подробнее. Я наверно что-то упустил, но всегда считал, что сам PHP не является таковым

PHP как язык - опенсурсная шляпа, но вот Zend Engine - это вполне себе коммерческая штука