Можно, при определенных условиях.
Вот, например, database.getStorage(StorageName.Matches); - что такое здесь database? Это твой объект?
Если его сразу создать со всеми возможными конфигами, то вполне можно затипизировать так, чтобы на каждое StorageName.NNNN возвращался Storage своего типа.
Ну а если ты сначала создаешь пустой database, а потом в разных файлах по отдельности накидываешь в него конфиги, то конечно никаких типов сохранить не получится.
Хотя, как вариант, database можно затипизировать неким интерфейсом, а потом в этот нитерфейс надобавлять информацию о типах. Но это по сути то же самое. Т.е. должен быть файл, где в одну кучу соберутся все типы для разных StorageName
johnymkp, когда ты работаешь с объектом matchStorageConfig из последнего куска кода, то всё хорошо - объект типизирован. Но как только попробуешь забирать что-то из storages из "общего конфига", и проверка типов исчезнет, будет any.
Вот взяли, например, dbConfig.storages[0]. К каким типам будешь приводить (any, any) ?
Ага, понял, спасибо. Сложность в том, что это делается для всплывашки-подсказки в ui-kit у нас на проекте, и должно работать в разных ситуациях. Конкретно здесь проблема в том, что див может, к примеру, частично перекрываться чем-то с z-index=1, и если чуть приподнять див, то данное перекрытие пропадет. Плюс могут быть вложенные контексты наложения, тогда предложенный вариант придется делать для каждого из них...
Собственно, потому и спрашивал. Чтобы прям можно было нативно "дырявить" оверлей по контурам конкретного элемента. В css много всякого появляется регулярно, я слегка отстал от переднего края..
Из первого равенства следует, что должно быть либо A(0, 0, 0)=1, либо B(1, 1, 1)=1, иными словами, нельзя одновременно A(0, 0, 0)=0 и B(1, 1, 1)=0
По второму всё сложно, там точно подходят все варианты А = В, кроме A(x,y,z) = B(x,y,z) = 0, исключаемого первым равенством. Но дополнительно ещё найдется куча вариантов, где A != B, при этом оба равенства соблюдены, например
A(x, y, z) = x & y & z
B(x, y, z) = x | y | z
и вот эти доп. пары непонятно как "классифицировать" и считать.
Можно, разумеется, выписать на бумаге все возможные пары функций, проверить их на соответствие равенствам и посчитать, но это уныние и отчаяние...
Здесь итоговый маршрут может проходить по комнате более одного раза, например если в примере оставить только комнаты 1, 2, 8, 4, 9, это не про Дейкстру
Re7r0, конечно! и отслеживание таймеров, и отправка данных происходят параллельно основному потому. В основном потоке только вызов wsClient.send - не сама отправка, а только лишь "просьба к системе отправить данные", но это копеечные расходы и они никого не блочат. Запихивать такое дело в отдельный поток - только зря тратить ресурсы.
Это, собственно, основа основ nodejs
Вот, например, database.getStorage(StorageName.Matches); - что такое здесь database? Это твой объект?
Если его сразу создать со всеми возможными конфигами, то вполне можно затипизировать так, чтобы на каждое StorageName.NNNN возвращался Storage своего типа.
Ну а если ты сначала создаешь пустой database, а потом в разных файлах по отдельности накидываешь в него конфиги, то конечно никаких типов сохранить не получится.
Хотя, как вариант, database можно затипизировать неким интерфейсом, а потом в этот нитерфейс надобавлять информацию о типах. Но это по сути то же самое. Т.е. должен быть файл, где в одну кучу соберутся все типы для разных StorageName