|
Ваши любимые костыли в конфигурациях 1С | ☑ | ||
---|---|---|---|---|
0
hi1C
09.12.19
✎
09:35
|
Добрый день коллеги! Не секрет, что костыли исправляющие поведение платформы проникли даже в БСП, см. ОбщегоНазначения.ЗначенияРеквизитовОбъекта. Поделитесь своими "любимыми" костылями.
|
|||
196
dmpl
09.12.19
✎
14:24
|
(194) Это так и было задумано :) Он поэтому и не ГУИД.
|
|||
197
hi1C
09.12.19
✎
14:33
|
(196) 1С ввела в заблуждение названием, надо было назвать ИногдаУникальныйИдентификатор
|
|||
198
ДенисЧ
09.12.19
✎
14:34
|
(197) Не иди по стопам 1с, не вводи в заблуждение окружающих.
Он уникальный. В пределах таблицы. |
|||
199
hi1C
09.12.19
✎
14:39
|
(198) ок, УникальныйИдентификаторВПределахТаблицы
|
|||
200
Cyberhawk
09.12.19
✎
14:42
|
(185) Скинь мне тоже пож-та (или в Телегу)
|
|||
201
Злопчинский
09.12.19
✎
14:43
|
одно время состав бухии менялся резвенько, и в торговой базе все время менялись бухи. причем у каждого нового - свой уникальный набор разрешений. достало. дал админские права в базе и все.
|
|||
202
hi1C
09.12.19
✎
14:44
|
Коллеги не стесняйтесь, делитесь любимыми костылями.
|
|||
203
Cyberhawk
09.12.19
✎
14:46
|
(202) Обертка для менеджера записи со свойствами как у набора записей (обменданными.загрузка и доп. свойства)
|
|||
204
hi1C
09.12.19
✎
14:48
|
(203) это круть :)
|
|||
205
hi1C
09.12.19
✎
14:48
|
(203) не могу представить зачем это
|
|||
206
Cyberhawk
09.12.19
✎
14:49
|
(205) Наглядность и краткость кода (как у МЗ) с использованием указанных выше двух возможностей, доступными только НЗ
|
|||
207
Cyberhawk
09.12.19
✎
14:49
|
*доступных
|
|||
208
hi1C
09.12.19
✎
14:50
|
(201) Права... сколько я повидал РС с названиями типа "Доп.права", "Динамические права" и т.д. с разным радиусом кривизны реализации.
|
|||
209
hi1C
09.12.19
✎
14:51
|
(206) ясно, я так привык к НЗ, глаз уже замылился, лет 5 наверное РЗ не использую
|
|||
210
hi1C
09.12.19
✎
14:51
|
(209) очепятка РЗ = МЗ
|
|||
211
hi1C
09.12.19
✎
14:53
|
а собственные индексы, привет соглашению с 1С, кто нибудь использует?
|
|||
212
Конструктор1С
09.12.19
✎
14:53
|
(154) и что, что на жаве?
|
|||
213
Конструктор1С
09.12.19
✎
14:54
|
(138) на жаве говнокодить можно, но делать это чуть сложнее, чем на 1с
|
|||
214
ДенисЧ
09.12.19
✎
14:54
|
(212) "язык должен быть серьёзным, без лишних волностей"
(с) Не Я |
|||
215
hi1C
09.12.19
✎
14:57
|
продолжу, флюент интерфейс через обработки, см. инфостарт
|
|||
216
Конструктор1С
09.12.19
✎
15:06
|
(140) ИМХО, дело не в нише, переваривающей говнокод. Платформа 1с это уже сам по себе некий стандарт. Ни один рукожом не сможет заставить справочник перестать быть справочником. Притащи с улицы любого 1сника, ткни пальцем в любой объект в дереве объектов конфигуратора, и этому 1снику будет понятно предопределенное поведение этого объекта, для чего и как он может быть использован. В то же время, на том же FoxPro городили кто во что горазд. Наверно поэтому FoxPro так и не доросла до серьёзных систем, застряв на уровне наколенных нетленок. Фузинцы решили повторить подвиги FoxPro, во что это вылилось сам видел: у них справочник это недосправочник-недоотчет-недорегистр в одном гранёном стакане. В то же самое время, на 1с такое нарукожопить сложно. Вот поэтому 1с и держится прочно в своей нише - у платформы большой запас прочности
|
|||
217
novichok79
09.12.19
✎
15:53
|
(86) (87) используется в фоновых заданиях, разумеется в основном потоке я не использую эту функцию.
|
|||
218
hi1C
09.12.19
✎
16:13
|
Замечательный костыль в БСП: ПроверитьПараметр.
Синтаксис Процедура ПроверитьПараметр(Знач ИмяПроцедурыИлиФункции, Знач ИмяПараметра, Знач ЗначениеПараметра, Знач ОжидаемыеТипы, Знач ОжидаемыеТипыСвойств = Неопределено) Экспорт Параметры ИмяПроцедурыИлиФункции - Строка - имя процедуры или функции, параметр которой проверяется. ИмяПараметра - Строка - имя проверяемого параметра процедуры или функции. ЗначениеПараметра - Произвольный - фактическое значение параметра. ОжидаемыеТипы - ОписаниеТипов, Тип, Массив, ФиксированныйМассив, Соответствие, ФиксированноеСоответствие - тип(ы) параметра процедуры или функции. ОжидаемыеТипыСвойств - Структура - если ожидаемый тип - структура, то в этом параметре можно указать типы ее свойств. У меня не типовая, с БСП близко не знаком. |
|||
219
hi1C
09.12.19
✎
16:31
|
в БСП, как в Греции, всё есть
ЭтоУникальныйИдентификатор Проверяет, является ли строка уникальным идентификатором. В качестве уникального идентификатора предполагается строка вида "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX", где X = [0..9,a..f]. Синтаксис Функция ЭтоУникальныйИдентификатор(Знач Значение) Экспорт Параметры Значение - Строка - проверяемая строка. Возвращаемое значение Булево - Истина, если переданная строка является уникальным идентификатором. |
|||
220
fisher
09.12.19
✎
16:33
|
(218) С принципе, мне нравится твоя философия. "Язык + костыли = программа". Как-то так оно в жизни и происходит.
|
|||
221
hi1C
09.12.19
✎
16:47
|
(220) Костыли неотъемлемая часть программы, невозможно всё впихнуть в язык. Но когда использование костыля становится массовым, мне кажется, что пора задумываться о включении его в язык. Если посмотреть синтакс-помощник можно найти методы которые не понятно кому нужны. Но они есть, а то что используется во всех типовых почему то в язык не включено. Где логика?
|
|||
222
palsergeich
09.12.19
✎
16:59
|
(221) логика в том что развитие языка идёт по плану.
Сначала появляются библиотеки, потом они становятся частью языка. Как это было например со строковыми функциями например |
|||
223
Конструктор1С
09.12.19
✎
17:05
|
(218)(219) не понятно, почему ты подобные библиотечные функции считаешь костылями? Например, ЭтоУникальныйИдентификатор() очень полезная функция при интеграции со сторонними системами
|
|||
224
hi1C
09.12.19
✎
17:14
|
(223) Костыль, в данном случае, то что могло быть в платформе. Но этого нет. Если бы это было разово разработано, каким то левым разработчиком, для узкой цели, то бог с ним. Но это применяется массово. Вот я не использую, БСП, сам виноват - знаю, мне нужно или самому писать что-то такое, либо искать написанной другими. Я и написал, через попытку.
|
|||
225
fisher
09.12.19
✎
17:41
|
(221) Частично так и происходит. Какие-то функции, ставшие стандартными в БСП, были впоследствии реализованы в языке. Вспомнить хотя бы ЗначениеЗаполнено, СтрШаблон и т.п. Но это касалось только очень простых и действительно очень массово и постоянно используемых функций.
(244) Вопрос в том, стоит ли в стандартную библиотеку языка тащить все полезные функции? Однозначно нет. Вот ты говоришь, что проверка на уникальный идентификатор применяется массово. Вопрос в том - насколько массово? Я вот лично ни разу не проверял. И почему-то мне кажется, что я не одинок. Тоже самое ПолучитьРеквизиты() - применяю чрезвычайно редко. Обычно удается писать так, чтобы получать все запросами одновременно с кучей других данных. А в простых и понятных случаях - смело работаю через точку. А вот ЗначениеЗаполнено() и СтрШаблон() - другое дело. Это нужно всем и каждому и нужно постоянно. |
|||
226
fisher
09.12.19
✎
17:45
|
Я могу понять, когда в платформу добавляют нечто, что не используется массово, но что сложно или неудобно реализовать на языке 1С, если это вдруг понадобится. Тут есть резон. А какой смысл включать в язык что-то, что массы каждый день не юзают, но что легко реализуется при необходимости и так?
|
|||
227
hi1C
09.12.19
✎
17:54
|
(226) ЗначениеЗаполнено так же легко реализуется
|
|||
228
fisher
09.12.19
✎
18:36
|
(227) Зато оно пригождается в каждой второй функции, кто бы и что бы не писал.
|
|||
229
Fragster
гуру
09.12.19
✎
18:51
|
Недавно такое в УТ видел:
Функция ВремяОжиданияИтерации(НомерИтерации) Если НомерИтерации < 15 Тогда ВремяОжидания = 1; Для НомерИтерации = 2 По НомерИтерации Цикл ВремяОжидания = ВремяОжидания * 1.4; КонецЦикла; Иначе ВремяОжидания = 120; КонецЕсли; Возврат ВремяОжидания; КонецФункции вроде переписали по человечески |
|||
230
Fragster
гуру
09.12.19
✎
18:52
|
интересно здесь вот это:
Для НомерИтерации = 2 По НомерИтерации Цикл (ну, кроме того, что все это в принципе говнокод) |
|||
231
DTX 4th
09.12.19
✎
18:59
|
Да, нет смысла тянуть ТЧ при обращении к реквизиту ссылки
(39) О, я себе недавно такое писал) (54) Ага, давайте лучше размажем простецкую конструкцию на 5 строк... (57) Достаточно просто не получать табличные части у ссылок.. Так извращаться ради реквизитов - оверхед Где голосовалка? Платформа выбешивает. Нельзя так наплевательски относится к разрабам. Не хватает вещей, который есть в других языках. И из-за отсутсвия ООП я даже не могу написать себе объект-помощник.... Где ++? Где лямба функции? LINQ бы не помешал С переходом на 8.3 могли бы добавить методы, которые конвертят ТЗ в массивы и наоборот. Но нет, верх всего происходящего - это долгожданное появление таких функций как СтрШаблон. Нет слов. |
|||
232
DTX 4th
09.12.19
✎
19:01
|
(230) Почему говнокод?
|
|||
233
Fragster
гуру
09.12.19
✎
19:05
|
(232) потому что этот код не работает (всегда одна итерация цикла), а также потому что возведение в степень есть в платформе.
|
|||
234
Fragster
гуру
09.12.19
✎
19:07
|
но знали ли вы, что предел цикла Для вычисляется один раз? и при этом после присвоения начального значения?
|
|||
235
DTX 4th
09.12.19
✎
19:22
|
(233) Если заменить переменную счетчика на другую, то имеет право на жизнь.
По (230) я подумал, что сама идея - говнокод. |
|||
236
Конструктор1С
09.12.19
✎
19:38
|
(231) "С переходом на 8.3 могли бы добавить методы, которые конвертят ТЗ в массивы и наоборот"
Так это же есть в БСП. К тому же не самая распространенная задача. В большинстве случаев не требуется гнать никакую табличку на клиент |
|||
237
Конструктор1С
09.12.19
✎
19:40
|
ООП - сомнительная необходимость в 1с. Сколько я ни спрашивал у апологетов ООП, никто так и не сумел привести примера надобности оной в 1с
|
|||
238
DTX 4th
09.12.19
✎
22:45
|
(236) В большинстве случаев и регистры расчета не нужны. Давайте их в БСП вынесем
(237) Достаточно будет инкапсуляции (да, я только что гуглил основные принципы). В наследовании основного смысла нет, ну а про инкапсуляции вы и сами понял xd Пример: Хочу сделать объект, который будет обрабатывать мою таблицу значений. Первый метод - возвращает сортированную, второй - конвертит в массив, и т.д. Текущие варианты реализации: 1. На ОФ можно сделать модули в виде форм. Как тиражное решение - никуда не годится. Крайне неудобно 2. На УФ? Ну на клиенте можно те же формы. А сервер? Инициализировать всё нужное в структуру, а потом гонять её по функциям, которые будут разбросаны вперемешку с основным кодом? https://i.ytimg.com/vi/HcfHBgUTn7I/maxresdefault.jpg |
|||
239
DTX 4th
10.12.19
✎
01:29
|
(238) "про инкапсуляции вы и сами понял" -> "про полиморфизм вы и сами поняли"
|
|||
240
Конструктор1С
10.12.19
✎
04:25
|
(238) инкапсуляция это не какие-то там возможности программирования. Это прежде всего принципы написания кода. Инкапсуляция была придумана ещё задолго до ООП, только пользовались ей лишь опытные разработчики, и держалась она на дисциплине при написании кода. В 1с есть всё необходимое, чтобы инкапсулировать алгоритмы. Ты можешь создать общий модуль, добавить в него экспортную процедуру, вспомагательные процедуры сделать не экспортными, и будет твой алгоритм инкапсулирован в самом полном смысле этого слова. А полиморфизм при динамической типизации, как мы уже выяснили, скорее источник проблем, чем благо
|
|||
241
ДенисЧ
10.12.19
✎
06:13
|
(240) Инкапсуляция - это в первую очередь про данные. Попробуй данные в модуль запихнуть )
|
|||
242
Конструктор1С
10.12.19
✎
08:01
|
(241) не-а, инкапсуляция это про скрытие деталей реализации. Скрытие данных тут скорее побочный бонусный эффект
|
|||
243
d4rkmesa
10.12.19
✎
08:46
|
(0) СтроковыеФункцииКлиентСервер.ПодставитьПараметрыВСтроку(...) - там, где СтрШаблон недоступен.
|
|||
244
vi0
10.12.19
✎
08:59
|
(216) "Платформа 1с это уже сам по себе некий стандарт"
"В то же время, на том же FoxPro городили кто во что горазд" Потому что 1с - это фреймворк, а фокспро - БД. |
|||
245
тарам пам пам
10.12.19
✎
09:07
|
(240) Мне лично в модулях нет нравится то, что из служебных модулей типа КлиентСервер и ПовтИсп их "потроха" торчат наружу в виде служебного интерфейса и приходится пользоваться соглашением, что на клиенте используем только модуль с припиской Клиент, на сервере - только вообще без приписок.
Также торчат наружу всякие подписки на события и обработчики регл. заданий. Ну и обработчики оповещений тоже. Так что инкапсуляция получается далеко не полной. |
|||
246
тарам пам пам
10.12.19
✎
09:08
|
(243) эти функции, кстати, не равнозначны - СтрШаблон падает при отсутствии локализованной строки, а ПодставитьПараметрыВСтроку() - не падает.
|
|||
247
ДенисЧ
10.12.19
✎
09:14
|
(244) Фокс - это не БД. Это СУБД.
|
|||
248
Bro
10.12.19
✎
09:18
|
(247) Строго говоря там логика представлений тоже была и достаточна развитая. Ну и много чего еще было. Так что все-таки это ближе к платформе было. Только она с внешними SQL дружила где-то на уровне Delphi, а когда SQL стал де факто стандартом в отрасли, все преимущества сошли на нет и Microsoft логично сделала ставку на .Net, похоронив Foxpro.
|
|||
249
Bro
10.12.19
✎
09:19
|
(248) Точнее даже так: на .Net и Axapta, причем их начали сильно сближать друг к другу, X++ используемый в Axapta сейчас очень похож на C#.
|
|||
250
hi1C
10.12.19
✎
09:21
|
(178)Это самое крутое что я видел за последние 3 года, да блин я с 7.7 таких хаков не встречал. Это просто песня!
|
|||
251
hi1C
10.12.19
✎
09:25
|
(249) Бро, у тебя во Фузине костыли есть? Делись :)
|
|||
252
trad
10.12.19
✎
09:28
|
(241) (242) согласен с ДенисЧ
толку от инкапсуляции реализации, без возможности завернуть в нее данные (состояние объекта) - не много |
|||
253
Bro
10.12.19
✎
09:43
|
(251) В самой фузине или в решениях на фузине?
|
|||
254
hi1C
10.12.19
✎
09:46
|
(253) в решениях
|
|||
255
vi0
10.12.19
✎
10:09
|
(247) не может быть такого)
|
|||
256
Bro
10.12.19
✎
10:09
|
(254) Ну то что сходу могу вспомнить:
При расчете себестоимости она выделяется в новый цикл в транзакции, а потом разбивается на итерации. https://github.com/lsfusion-solutions/mycompany/blob/c2ca9254b4dce33988073b5b1d7ee105029561a0/src/main/lsfusion/inventory/ledgers/CostLedger.lsf#L47 Плюс например в ERP очень сильно намудрили с видами цен, замкнув все на одну функцию цена от любого вида цены (а видов цен там десятки, а то и сотни). Соответственно если начать компилировать из этого один запрос он получится очень большим. В итоге иногда делают выверты с событиями на изменения видимой части таблицы: // определяется когда пересчитывать отображаемую цену. WHEN LOCAL FORMS userOrder (SET([ VIEW userOrder.sts](Stock stock, Sku sku)) AND currentUserOrderUserOrder() = UserOrder o) OR ((CHANGED(priceDateTime(o)) OR CHANGED(priceListType(o)) OR CHANGED(agreement(o))) AND [ VIEW userOrder.sts](stock, sku)) DO updateViewPrice(sku, stock, o); ; // читают цену в локальное свойство (временную таблицу), причем пометка NOINLINE означает что надо выполнять FOR по каждому виду цены в отдельности, а по складам, товарам и датам одним запросом updateViewPrice (Sku sku, Stock stock, UserOrder userOrder) { FOR PriceListType pt = priceListType(userOrder, sku) AND (Stock st = IF overPriceStockUser(userOrder) THEN overPriceStockUser(userOrder) ELSE stock) AND stock IS Stock AND DATETIME dt = priceDateTime(userOrder) NOINLINE (pt) DO viewPrice(sku, stock, userOrder) <- prevPriceB(pt, sku, st, dt); } ну и еще есть пару хаков в таком духе. В общем есть свои скелеты, когда оптимизацию выполняют тоже руками за платформу. Но тьфу-тьфу на проект в несколько сотен тысяч строк, их с пару десятков и они локализованы. Ну и мелочи которые недоделали. Например отсутствие вывода типа из равенства (то есть PriceListType в примере платформа могла бы сама определить), ну и в таком духе из чего иногда получаются java проблемы вроде Борщ борщ new Борщ. |
|||
257
Mort
10.12.19
✎
10:14
|
Процедура ПриЧтенииСозданииНаСервере()
{ } |
|||
258
hi1C
10.12.19
✎
10:20
|
(257) в чем костыльность? простите я не понял
|
|||
259
hi1C
10.12.19
✎
10:31
|
(256) интересно, разработчики платформы так же отслеживают костыли?
|
|||
260
Mort
10.12.19
✎
10:33
|
(258) В том, что практически в каждой форме объекта эта конструкция нагорожена. Просто отсутствует удобный обработчик формы для заполнения реквизитов формы зависящих от данных объекта (вне зависимости от того новый он или нет).
|
|||
261
hi1C
10.12.19
✎
10:38
|
(260) меня фигурные скобки сбили с толку, типовые конфигурации?
|
|||
262
Bro
10.12.19
✎
10:47
|
(259) Интересный вопрос. Потому как природа человека такая что если он нашел workaround, он часто не то что не зарепортит, а наоборот будет ходить довольный какой он умный. :) Думаю при разработки типовых в 1С та же фигня.
|
|||
263
Конструктор1С
10.12.19
✎
10:51
|
(244) вообще фокспро СУБД, но использовалась она для тех же целей, что и 1с
|
|||
264
Конструктор1С
10.12.19
✎
10:55
|
(252) ну как это нет толку? Помнишь эпопею со ставками НДС в конце прошлого года? Добавилось новое значение перечисления СтавкиНДС, а меняли код в тыще мест. Этого не было бы, если бы расчет размера НДС был инкапсулирован в отдельном модуле. Тогда обошлось бы исправлением нескольких строк кода
|
|||
265
hi1C
10.12.19
✎
11:25
|
(264) это и без ООП можно реализовать
|
|||
266
pechkin
10.12.19
✎
11:29
|
сейчас вообще в моде функциональщина, там ооп не нужно
|
|||
267
pechkin
10.12.19
✎
11:29
|
(264) основная проблема в запросах, там никак общим модулем не обойдешься.
ибо функций для запросов нет |
|||
268
Конструктор1С
10.12.19
✎
11:33
|
(265) естественно. Я про то и пишу, что инкапсуляция возможна и без ООП
|
|||
269
Bro
10.12.19
✎
11:34
|
(266) функциональщина и наследование / полиморфизм (а это основа ООП) это строго говоря две перпендикулярные вещи.
|
|||
270
Конструктор1С
10.12.19
✎
11:36
|
(267) это уже вопрос написания кода и запросов. Достаточно оставить болезненную, но популярную манеру делать вычисления в запросе, и всё будет тип-топ. В отчетах на СКД можно подтянуть глобальную функцию, в простых запросах делать все расчеты при выборке
|
|||
271
pechkin
10.12.19
✎
11:38
|
(269) речь про то что ооп - это стейт, а функциональщина - это как раз отсутствие стейта
|
|||
272
hi1C
10.12.19
✎
11:47
|
(271) интересная статья на эту тему https://habr.com/ru/post/479238/
|
|||
273
Fragster
гуру
10.12.19
✎
11:49
|
(235) сама идея делать это циклом - тоже говнокод
|
|||
274
hi1C
10.12.19
✎
11:50
|
(270) текст запрос можно собирать
|
|||
275
hi1C
10.12.19
✎
12:01
|
Выжимка из https://habr.com/ru/post/479238/: Отсутствие эффектов это единственное требование, которое нужно соблюдать, чтобы программа была функциональной.
|
|||
276
Fragster
гуру
10.12.19
✎
12:04
|
(275) ну так не пиши инчего в базу тогда
|
|||
277
pechkin
10.12.19
✎
12:12
|
(274) это как раз bad practice
|
|||
278
pechkin
10.12.19
✎
12:12
|
(276) там решается через DI и проброса объекта записывающего в базу
|
|||
279
Fragster
гуру
10.12.19
✎
12:41
|
(278) нет, это не ФП.
|
|||
280
hi1C
10.12.19
✎
13:09
|
(277) коллеги подсказывают, что в ЗУПе применяется очень активно сбор текста запроса
|
|||
281
pechkin
10.12.19
✎
13:12
|
(280) зуп - это воообще сборник лютых bad practice
|
|||
282
pechkin
10.12.19
✎
13:13
|
(279) ну так сам объект пишущий не фп, а все останое фп
|
|||
283
Конструктор1С
10.12.19
✎
13:32
|
(280) ну это не значит, что надо делать также
|
|||
284
Paint_NET
10.12.19
✎
13:33
|
(280) Опыт подсказывает, что модули ЗУПа писали крайне упоротые наркоманы.
|
|||
285
Cyberhawk
10.12.19
✎
13:34
|
(273) А возведение в степень - не цикл?
|
|||
286
Fragster
гуру
10.12.19
✎
13:39
|
(285) не всегда, и что там в процессоре при этом происходит - хз вообще. Факт в том, что на языке платформы писать 5 операторов вместо одного - неправильно.
|
|||
287
palsergeich
10.12.19
✎
14:02
|
(284) Дык дело не в конфе.
Разработчики ЗУП для того что бы разрабатывать должны быть упороты так же как и законотворцы, если не дунуть то ничего не получится (Амаяк Акопян) |
|||
288
palsergeich
10.12.19
✎
14:03
|
(285) возведение в степень можно реализовать байтодрочерством, я помню на лабах в c++ мы делали такую хрень
|
|||
289
mistеr
10.12.19
✎
14:37
|
Поделюсь тем, что бесит меня, хоть костыля нет (и бесит в т.ч. потому, что и костыля не сделать). Невозможность обхода результата запроса (произвольного) без загрузки его целиком в память.
По сабжу. Не всё, что "могло бы быть в платформе", должно быть непременно в платформе. Например, ПроверитьПараметр() - вполне норм. |
|||
290
mistеr
10.12.19
✎
14:40
|
(289) Надеюсь, в фузине это не проблема )
|
|||
291
hi1C
10.12.19
✎
14:41
|
(289) ПроверитьПараметр - это было бы не нужно, если бы можно было типизировать параметры методов.
|
|||
292
pechkin
10.12.19
✎
14:42
|
а что значит ПроверитьПараметр?
|
|||
293
hi1C
10.12.19
✎
14:43
|
(292) см (218)
|
|||
294
mistеr
10.12.19
✎
14:46
|
(291) Нужно. Параметры бывает нужно проверять не только на тип. Но в слабо типизированных языках — ещё и на тип. Это нормально.
А бывает, не нужно проверять тип, например, любая коллекция годится. |
|||
295
hi1C
10.12.19
✎
15:16
|
(294) хотел написать про то что было бы хорошо если бы платформа проверяла тип, но передумал
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |