Интерфейсы и модульность

Запись от CoderHuligan размещена 30.01.2024 в 17:15

Показов 5037 Комментарии 62

Слово "интерфейс" происходит от двух слов - inter (между) и face (лицо), т. е. то что находится между лицами. Как взаимодействуют между собой к примеру люди? Посредством языка, т.е. того, что является интерфейсом между двумя и более, лицами. Без интерфейса взаимодействие невозможно. Даже язык жестов является таким же интерфейсом, как и любой другой язык.
Сразу отмечу, что любой язык как интерфейс, является чисто внешней сущностью, которая вполне независима от лиц её использующих. Причем одно лицо может пользоваться разными интерфейсами (языками).
Итак, любой интерфейс это язык (если он интерфейс).
Причем не может быть так, что одно лицо имеет свой уникальный интерфейс, а другое свой. Тогда взаимообщение лиц попросту невозможно или было бы затруднено. Гораздо выгоднее иметь универсальный в рамках какой-то общности интерфейс. Во всяком случае к этому стоит стремиться.
Если речь идет о программировании, тот тут мы часто имеем ввиду взаимодействие модулей/классов.
Модули в языке Паскаль, по моему, есть чисто искусственное явление. Язык Дельфи это унаследовал. Язык Оберон, потомок Модулы, имеет загружаемые по требованию модули, и это уже большой шаг вперед. Но мы о другом.
Классы в ООП, как и модули Паскаля, предоставляют свой интерфейс во внешний мир, делая доступными для него свои паблик поля, или через геттеры и сеттеры, что в общем одно и тоже: мы приоткрываем внутренности модуля/класса внешнему миру.
Казалось бы: а как иначе? Как иначе строить взаимодействие между модулями/классами?
Проблема тут одна: каждый отдельный модуль/класс предоставляет во внешний мир свой собственный интерфейс, а значит и язык, который обязаны знать все остальные. А я уже писал, что лучше иметь универсальный язык.
Проблема возникает, когда мы хотим изменить модуль/класс. Допустим хотим добавить в паблик функцию еще один параметр. Если это сделать, то мы должны будем изменить все модули/классы, которые пользуются интерфейсом этого модуля/класса.
Предоставляя внешнему миру даже свои паблик поля, мы связываем этот внешний мир с конкретным классом. Это всегда проблемы.
Выходом из положения может быть создание особого языка (именно языка!), который бы разделяли все модули системы. Когда мы вызываем публичную функцию какого-то класса или пользуемся переменной, мы по сути становимся заложниками имен этих сущностей, их типов и их сигнатур.
Если бы каждый модуль ничего не знал о других модулях, но просто посылал сообщение и параметры через некий общий для всех интерфейсный модуль, посредством особого универсального языка, то отпала бы необходимость в глобальных данных, что всегда проблемы, а также изменение одного модуля не влияло бы на другие, так как ни один модуль ничего не знает о других, кроме универсального языка, который все модули должны поддерживать. Тогда не потребуются и области имен.
Повторяю: один язык лучше, чем много уникальных языков.
Ну а реализацию данного механизма лучше поручить особому языку программирования, который бы скрывал детали реализации межмодульного взаимодействия, предоставляя универсальные механизмы по передаче/получении сообщений. Вот это и будет подлинное ООП..

Размещено в Без категории

« Как избавиться от циклов Главная страница Как запомнить знаковые и беззнаковые диапазоны максимальных значений »

Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.

Всего комментариев 62

Комментарии

2 из 4

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

Запись от CoderHuligan размещена 31.01.2024 в 17:54 CoderHuligan вне форума

Сообщение от CoderHuligan

Нет. Так как сообщение уникально и привязано к конкретному модулю, который его объявил, то получатель данного сообщения всегда этот конкретный модуль.

А как же "не должен знать имя модуля"? Т.е. остается жесткая привязка?

Сообщение от CoderHuligan

А если нам нужно заменить или изменить модуль, то все остается в силе если придерживаться соглашений.

Так эту роль сейчас выполняют интерфейсы - они интуитивно понятны, читаемы. Нет необходимости лезть в базу. При чем как раз таки минус подхода с применением сообщений, что нет ясного понимания при отладке. Т.е. поймает ваш меседж из за какого то бага другая ловушка и вы замучаетесь ее искать. (утрировано конечно, но тем не менее) это уже из существующего
опыта. Плюсы конечно то же есть. Но это и один из пунктов, который учитывается применяем сообщения или просто вызываем с указанием интерфейса, а не класса.

Сообщение от CoderHuligan

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

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

Сообщение от CoderHuligan

Очень многое. Вам же всё равно нужно будет получить доступ к конкретному методу объекта через точку.

Ну а вы все равно будете регистрировать. Экземпляры то в любом случае вы должны создавать.

PHP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
//Вася  создал
class MegaLogger implements Psr\Log\LoggerInterface
{
 
}
// Петя создал
class SomeService{
   function __constructor(
      private readonly Psr\Log\LoggerInterface $logger
   ) {
   }
    public function execute():void {
      $this->logger->debug('test');
    }
}
// Илья использует это в своем приложении
$logger= new MegaLogger();
//....
$service  = new SomeService($logger);
//... 
$service->execute();
 
// Но можно и с переделать на сообщения
class EventBus {
    public function register(string $message, \Closure $handler):void{
    }
    public function emit(string $message, mixed $data):void{
    }
}
// Вася  создал
class MegaLogger implements Psr\Log\LoggerInterface
{
   function __constructor(
     private readonly EventBus $eventBus
   ) {
  }      
 
}
// Петя создал
class SomeService{
   function __constructor(
     private readonly EventBus $eventBus
   ) {
   }
    public function execute():void {
      $this->eventBus->emit('log.debug', 'test');
    }
}
// Илья использует это в своем приложении
$logger = new MegaLogger();
$service = new SomeService();
$eventBus = new EventBus();
$eventBus->register('log.debug',$logger->debug(...));
$eventBus->register('executeProcess',$service->execute(...));
//......
 
$eventBus->emit('executeProcess',null);

Т.е. один фиг нужен интерфейс.

Сообщение от CoderHuligan

Еще хуже когда классы имеют свою область имен.

Вообще не понятно чем хуже?
в маленьких задачках просто не используйте. На больших.... это будет жесть вы сами же повеситесь. У меня есть сайт в работе где есть несколько модулей от нескольких разработчиков имеющих одноименные классы. И как тут быть?

Да и сообщения тоже не все так просто... Я назвал сообщение "dev.test" и вы так же.... И что будет делать ваша шина .ообщений? Потому еще в примере выше надо добавлять и от кого сообщение. Потом одно сообщение надо дождаться результата, у другого вообще все пофиг... т.е. на пустом месте вы можете огрести кучу неоднозначностей. все решаемо безусловно, просто я к тому, что то что вы предлагаете, оно уже есть по сути, только оно решает другие задачи, не решает то, что вы озвучили, и не стоит тащить в любой проект без разбора. Потому что легко появится рядом с вашим блогом такой же где будет звучать что то типа

Еще хуже когда классы общаются сообщениями, давайте изобретать неймспесы.

Запись от voral размещена 31.01.2024 в 18:31 voral на форуме

А как же "не должен знать имя модуля"? Т.е. остается жесткая привязка?

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

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

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

Конечно. И эти правила жестко прописываются в протоколе и в документации на модуль. Так легче тестировать систему. Повторяю: не может быть такого, что сообщение поймает кто-то другой. Кто создал протокол,тот и поймает. Система должна гарантировать уникальность сообщения. А для чего тогда создали COM технологию? Для легкости межмодульного взаимодействия. Именно там уникальные идентификаторы гарантируются системой.

Ну а вы все равно будете регистрировать. Экземпляры то в любом случае вы должны создавать.

Резонный вопрос, но только при традиционном мышлении. Создать объект, это не значит обязательно лезть в его внутренности. СоздатьЮзера($user); не одно и то же, что и: $user = new Users(); В первом случае мы не знаем имя класса. И нам не нужен доступ через точку. Мы просто посылаем сообщение: $SetNameClient("вася", user);

Вообще не понятно чем хуже?

Загромождают код. Такой код трудно читать.

Я назвал сообщение "dev.test" и вы так же.... И что будет делать ваша шина .ообщений?

Не может такого быть.

Запись от CoderHuligan размещена 31.01.2024 в 19:03 CoderHuligan вне форума

Сообщение от CoderHuligan

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

Сообщение от CoderHuligan

Это вообще просто хотелка. А так пожалуйста в том же php есть FFI . Можете использовать библиотки (dll) написанные на любом ЯП.

Сообщение от CoderHuligan

Конечно. И эти правила жестко прописываются в протоколе и в документации на модуль. Так легче тестировать систему.

Нет ни чем не легче. В доку лезть? а сейчас мне этого не нужно делать. ИДЕ контролирует это "автоматом". В компилируемых еще и компиляция обломается. Тестировать так сложнее. Потому что связи становятся не очевидными.

Сообщение от CoderHuligan

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

Ну и что вы новго предлагаете, кроме того, что нашли замену "интерефейсу" (правда не отменяя интерфейсы)

Сообщение от CoderHuligan

СоздатьЮзера($user); не одно и то же, что и: $user = new Users();

Вы сравниваете совершенно разные сущности. Непосредственное создание объекта и фабрику объектов. Я могу сделать (и это тоже применяется, что бы было createUser($user) и точно так же по схеме как я приводил выше сделать это с использованием шины сообщений.

Сообщение от CoderHuligan

Загромождают код. Такой код трудно читать.

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

Сообщение от CoderHuligan

Не может такого быть.

Значит должен быть некий протокол/интерфейс... т.е. пришли к тому, от чего пытались уйти

Запись от voral размещена 31.01.2024 в 19:13 voral на форуме

Проблема в том, что когда мы вызываем код из другого модуля, он тянет за собой зависимости. К примеру в другом модуле функция, которую мы вызываем, оперирует с глобальной переменной в модуле. Если у нас есть переменная с тем же именем, она будет конфликтовать с той. Обходят эти проблемы с помощью неймспейсов, подключаемых файлов и модулей. Но тут возникает вопрос: а зачем? Зачем подключать внутренности других модулей в тело данного? Это же бред чистой воды! Как можно взять иной файл и буквально вписать его внутрь данного? А ведь это и происходит, когда мы подключаем хедеры. Положение спасает, что мы подключаем только интерфейсы. Но всё равно они могут тянуть зависимости. Придумали костыль в виде неймспейсов. Придумали то придумали, но только усложнили жизнь тем, кто разбирает такой код.
А всё потому, что путем простого взгляда на код мы уже не можем четко понять: что от чего зависит без необходимости лезть в другие файлы. И вот это ползание по другим файлам отнимает кучу времени.
В идеале у нас вообще нет никаких подключаемых файлов. А значит нет и зависимостей, неймспейсов, конфликта имен. Более того: у нас теперь нет и компоновщиков(линкеров).. Потому что нечего компоновать. Модуль компилиться отдельно от всех остальных. Каждый модуль грузится по требованию автоматически когда в нем есть необходимость. Вот в чем новизна: в упрощении инструментов. А значит в упрощении поддержки такого кода. Некоторые люди хотят все усложнить, другие упростить. Упрощение не выгодно бизнесу, но выгодно любителям.
После компиляции, допустим, мы создали текстовый файл с asm кодом, который затем можно отдать ассемблеру. Но так как он текстовый, а не бинарный, как сейчас обьектные модули, то его можно поправить в части асм кода, а потом уж отдать ассемблеру. Но это лишь один частный момент из многих возможных моментов которые упрощают жизнь и делают её приятной.

Запись от CoderHuligan размещена 04.02.2024 в 12:47 CoderHuligan вне форума

На самом деле, даже накладных расходов можно избежать, если компилятор просто подставит на место операции посылки сообщения реальный вызов необходимой функции из другой области трансляции. Причем эта функция будет"видеть" лишь свою область видимости, в которой определена, а не ту, в которую она подставляется. Но в этом случае придется распрощаться с идеей отложенной загрузки модуля по первому требованию. Короче говоря, надо сделать тестовый ЯП. Сперва игрушечный, но с поддержкой данной концепции. И посмотреть что из этого выйдет..

Запись от CoderHuligan размещена 04.02.2024 в 19:05 CoderHuligan вне форума

Сообщение от CoderHuligan

Такие проблемы решают грамотными подходами разработки - глобальные переменные зло.

Неймспейсы не для этого.

Сообщение от CoderHuligan

Но тут возникает вопрос: а зачем? Зачем подключать внутренности других модулей в тело данного? Это же бред чистой воды!

Конечно. По этому так ни кто и не делает. Что за подключение внутренностей? Зачем?

Сообщение от CoderHuligan

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

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

Сообщение от CoderHuligan

Придумали костыль в виде неймспейсов. Придумали то придумали, но только усложнили жизнь тем, кто разбирает такой код.

Не согласен более чем полностью. Попробjвал представить все текущие мои проект без неймспесов... Да ну нахрен.. Такой взрыв мозга будет. Ну просто поясните мне вот Вася в своем модуле сделал класс User, я сделал класс User.... А теперь пишем new User. И?

Сообщение от CoderHuligan

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

Ну это только если бардак в коде и неграмотное отношение. Я даже не представляю чего тут сложного. Зачем лезть?
т.е. если вы видите подключенный заголовок в коде то у вас возникает вопрос что от чего зависит? брррр.....

Сообщение от CoderHuligan

В идеале у нас вообще нет никаких подключаемых файлов. А значит нет и зависимостей, неймспейсов, конфликта имен. Более того: у нас теперь нет и компоновщиков(линкеров).. Потому что нечего компоновать.

Из серии создания кнопки "сделать звездато"

Сообщение от CoderHuligan

Модуль компилиться отдельно от всех остальных. Каждый модуль грузится по требованию автоматически когда в нем есть необходимость.

В чем проблема? Модули хоть обкомпилируйтесь по отдельности. Загрузка.. Ленивая инициализация..... обыденная практика.

Сообщение от CoderHuligan

Вот в чем новизна: в упрощении инструментов. А значит в упрощении поддержки такого кода.

Не понятно в чем упрощение? В какой то внтуреней магии, которая будет угадывать какой класс User мне нужен?

Сообщение от CoderHuligan

Упрощение не выгодно бизнесу, но выгодно любителям.

Полный бред. Бизнесу выгодно минимизирвоать вложения в процесс разработки. Это снижение себестоимости. Усложнять разработку и повышать ее стоимость - в чем логика то? Т.е. сидит такой дебил бизнесмен, продает ПО за 100 руб, и думает как бы разработчику (сотруднику) заплатить за это не 50 руб а все 100?

Сообщение от CoderHuligan

После компиляции, допустим, мы создали текстовый файл с asm кодом, который затем можно отдать ассемблеру.

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

Запись от voral размещена 05.02.2024 в 01:43 voral на форуме

Упрощение не выгодно бизнесу

Конечно. Бизнес же любит на разработку тратить неограниченные суммы. Бизнесмены же дебилы через одного.

А, так, я смотрю ты для себя шину сообщений открыл?)

Запись от Usaga размещена 05.02.2024 в 10:36 Usaga вне форума

Сообщение от CoderHuligan

На самом деле, даже накладных расходов можно избежать, если компилятор просто подставит на место операции посылки сообщения реальный вызов необходимой функции из другой области трансляции. Причем эта функция будет"видеть" лишь свою область видимости, в которой определена, а не ту, в которую она подставляется.
Но в этом случае придется распрощаться с идеей отложенной загрузки модуля по первому требованию. Короче говоря, надо сделать тестовый ЯП. Сперва игрушечный, но с поддержкой данной концепции. И посмотреть что из этого выйдет..

Хм.

index.php
создал простенький автолоадер классов для демонстрации, далее создается шина сообщений, регистрируется сообщение и обработчик. Обратите внимание передал именно функцию , вообще безымянную. При этом перед ней есть static. Как раз с этим или без этого - я управляю областью видимости, внутри этой функции - т.е. управляю чего она видеть, как вы и хотели.

PHP
1
2
3
4
5
6
7
8
9
10
11
12
<?php
spl_autoload_register(function (string $className) {
    include $className . '.php';
});
 
$eventBus  = new EventBus();
$eventBus->register('exec',static function():void {
    $service= new Service();
    $service->process();
});
 
$eventBus->emit('exec');

EventBus.php
создал простенькую шину сообщений. В начале файла вывод строки о том что данный файл подключен.

PHP
1
2
3
4
5
6
7
8
9
10
11
12
13
<?php
echo "Included: ",__FILE__,"<br>";
class EventBus{
    private array $registry =[];
    public function register(string $event, Closure $handler):void{
        $this->registry[$event] = $handler;
    }
    public function emit(string $event):void{
        if (array_key_exists($event,$this->registry)) {
            $this->registry[$event]();
        }
    }
}

Service.php
Так же строка, которая просимофорит когда этот файл был подключен. Ну и просто некий класс выполняющий некую бизнес- логику приложения

PHP
1
2
3
4
5
6
7
8
<?php
echo "Included: ",__FILE__,"<br>";
 
class Service {
    public function process():void{
        echo "Executed<br>";
    }
}

Итак в файл index.php убираем строку $eventBus->emit('exec');

Приложение нам выведет. Как виден при вызове index.php подключен только один дополнительный файл

Bash
1
Included: /var/www/EventBus.php

Возвращаем строку $eventBus->emit('exec');

Bash
1
2
3
Included: /var/www/EventBus.php
Included: /var/www/Service.php
Executed

Как видим, подключился еще один файл, создался объект и выполнился его метод только когда было отправлено сообщение 'exec'

Вот вам онлайн песочница - можете поиграть этим примером. Я вам дал "игрушечный ЯП"

Запись от voral размещена 05.02.2024 в 12:23 voral на форуме

Ну просто поясните мне вот Вася в своем модуле сделал класс User, я сделал класс User.... А теперь пишем new User. И?

Это называется шаблонным мышлением. За создание юзера отвечает единственный модуль. Вася послал сообщение создать нового юзера. Модуль создает его. Надо изменить свойства? Посылаем сообщение $setUserName($id=1, "Petya")
И это не одно и тоже. Мы тут общаемся через интерфейс, который описывает только то, что нам нужно сделать. У нас нет искусственных неймспейсов и имен модулей, имен полей свойств и имен методов.

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

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

Не понятно в чем упрощение? В какой то внтуреней магии, которая будет угадывать какой класс User мне нужен?

Не во внутренней магии. А в понятном и прозрачном механизме, который изолирует один модуль от другого. По сути контрактное программирование где спецификации упрятаны внутри компилятора. На верху мы имеем только шину сообщений и реестр сообщений. Так как каждое сообщение по существу является уникальной сущностью, которая описывает часть логики работы программы, то оно совершенно оправданно. Между тем как все эти std и пр. по сути есть неоправданные сущности. То есть чисто искусственные образования только захламляющие листинги ненужными лексемами, и заставляющие программистов лишний раз пробегать глазами по ним, утомляя зрение и теряя время.

Это снижение себестоимости. Усложнять разработку и повышать ее стоимость - в чем логика то? Т.е. сидит такой дебил бизнесмен, продает ПО за 100 руб, и думает как бы разработчику (сотруднику) заплатить за это не 50 руб а все 100?

Чем сложнее инструменты, тем меньше конкуренции, тем больше зарплаты, в том числе и выше прибыль из-за завышенных цен на ПО.

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

Я вам дал "игрушечный ЯП"

Я и на Си мог бы нечто подобное сделать. Эмулировать можно, кто бы сомневался. Только смотрите сколько ненужных телодвижений вы тут нагородили.
Но вы молодец. Я бы так не смог. На php писал только с процедурном стиле. Сейчас изучаю javascript. Круто, ничего не скажешь..

Запись от CoderHuligan размещена 05.02.2024 в 16:09 CoderHuligan вне форума

Уточню. Каждый модуль может зарегистрировать некий алиас - имя сообщения, количество и тип параметров. Это для экспорта. Модуль,который что-то импортирует, просто передает сообщение в виде этого алиаса(псевдонима) реальной функции некоему серверу, который и вызывает реальную функцию в другом модуле. То есть, с точки зрения организации кода мало что поменялось. Просто нам теперь ненужно подключать другие модули явно. А так как при регистрации сообщений происходит проверка на уникальность, то мы избавляемся от конфликтов имен. То есть в каждом модуле код можно писать не думая об этом. Это спасает от трудноуловимых ошибок при файловой организации о чем упоминал Страуструп в своей книге. Глобален у нас только метаязык сообщений. Данные передаются традиционно, либо по значению либо по ссылке.

Запись от CoderHuligan размещена 05.02.2024 в 17:55 CoderHuligan вне форума

Сообщение от CoderHuligan

Это называется реальным проектом:
1. Могут быть использованы готовые модули сторонних разработчиков. С вашим подходом это становится не возможным, да и в большой распределенной команде становится затруднительным
2. Единственный модуль отвечающий за пользователя, в большом проекте эта архитектурная ошибка, которая может привести к неоправданной не стабильности. Предположим вы ради чатика внутри приложения решили добавить цвет аватарки пользователя. Изменяете тот класс который отвечает и за авторизацию.... задача простая - можно поручить джуну..... и он благополучно делает дыру в системе авторизации..... Нет... Для мелких проектиов единый класс возможно оправдан, но вот разделение по зонам ответственности весьма оправдано. Это только в представлении неопытного "шаблонное мышление". В реальности же это опыт проблем проектов.

Так что вопрос в силе. У нас подключен сторонний модуль- он отлично работает. И имеет свой класс User. И у нас в проекте есть такой класс. Как вы будете разруливать?

Сообщение от CoderHuligan

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

Очевидно у вас уйма свободного времени

1 Современные ИДЕ подсветят если подключено нечто. что не используется.
2 Хороший нейминг дает представление о том, что подключено

Сообщение от CoderHuligan

Вам уже несколько раз в этой теме сказали, что это уже давно изобретено и применяется

Сообщение от CoderHuligan

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

Это возможно только в очень мелких проектах.

Сообщение от CoderHuligan

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

Бред более чем. Сомневаюсь, что вы найдете тех кто много работает над реальными проектами и согласится с вами.

Вы не избавитесь от неймспейсов по сути - вы просто будете выдумывать более длинные имена классам, чтобы обеспечить их "уникальность"..

К пример, по объективным причинам в проекте нам понадобился такой класс:
External\Accounting\User - т.е. неймспейсы дают важную информацию о том что это за класс.
Вам же придется писать ExternalAccountingUser Пока примерно одинаково, привычный вариант более читаем на мой взгляд (но да ладно - это вкусовщина)... Только вот я могу в коде писать (при использвоании этого класса) такие варианты в зависимости от ситуации

External\Accounting\User
Accounting\User
User
+ еще возможность алиасов

у вас же всегда будет длинное ExternalAccountingUser

И это еще простенький с тремя уровнями.. АВ большом проекте у вас появятся классы и по 70 символов, ради "уникальности"

Сообщение от CoderHuligan

Полная глупость. Если бы вы были правы сейчас бы был только ассемблер, или вообще в машинных кода писались программы. Между тем та же Java - по сути рождена (утрировано) для ускорения разработки в ущерб производительности .

Сообщение от CoderHuligan

Кто вам это сказал? Хорошо, что я не знал, а то б у меня не получилось: написал на сях либу самую простейшую, и подключил ее в PHP проекте... Подскажите как надо указывать целевой ЯП?

Сообщение от CoderHuligan

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

Какие тут телодвижения лишние?

Запись от voral размещена 05.02.2024 в 20:05 voral на форуме

Сообщение от CoderHuligan

По сути я это и продемонстрировал.

Сообщение от CoderHuligan

А так как при регистрации сообщений происходит проверка на уникальность, то мы избавляемся от конфликтов имен.

1 Проверка это лишь проверка. Но, что будет если уникальность нарушена
2. Вы регистрируете уже модули просто иначе - меняется только синтаксис

Сообщение от CoderHuligan

То есть в каждом модуле код можно писать не думая об этом.

Это и сейчас так.

Сообщение от CoderHuligan

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

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

Только надо иметь ввиду ради мелких проектов вообще нет смысла парится. А в сложных вы замучаетесь с вашим подходом. Не очевидно будет практически все.. А код будет представлять из себя трудночитаемые простыни.

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

Запись от voral размещена 06.02.2024 в 01:43 voral на форуме

Пока вы не поясните как вы разрулите конфликты имен - нет смысла даже обсуждать...

Вася создал модуль с классом "user". Федя создал модуль (библиотеку) с названием "user". Нам требуется подключить два этих модуля к своему проекту, в котором у нас также есть "user". Мы просто создаем свой алиас для каждого подключаемого модуля. Системная функция каждому подключаемому модулю дает идентификатор-число. Оно привязывается к алиасу. Поэтому разрешение имен идет на внутреннем уровне без участия программиста. Его дело создать алиас, а система подскажет уникален ли он на уровне проекта или нет. Так что никаких проблем тут нет.
Однако, согласен, что придется применять этот алиас к сообщению, иначе трудно понять каким образом подключать библиотеки.

Запись от CoderHuligan размещена 10.02.2024 в 10:11 CoderHuligan вне форума

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

Ну допустим вы научите где то под капотом это все "разруливать". Но это будет дополнительная логика. Являющаяся по сути костылем. Да и,по большому счету, все придет к тому, что будет все тоже самое как и с неймспейсами только сложнее.

В итоге будет все гораздо запутаннее и не надежнее.

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

Опять же то что я выше уже приводил
я могу сейчас с неймспейсами в коде писать
External\Accounting\User
Accounting\User
User
+ еще возможность алиасов

у вас же всегда будет длинный алиас ExternalAccountingUser

Запись от voral размещена 10.02.2024 в 13:17 voral на форуме

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

Запись от voral размещена 10.02.2024 в 13:19 voral на форуме

Все три модуля используют четвертый (один и тот же модуль, например шифрующий модуль, назовем его hash. И во всех трех случаях ему дадут свои алиасы, система это все три раза зарегистрирует.

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

Опять же то что я выше уже приводил
я могу сейчас с неймспейсами в коде писать
External\Accounting\User
Accounting\User
User
+ еще возможность алиасов

у вас же всегда будет длинный алиас ExternalAccountingUser

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

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

Да. Расшифровкой что где лежит должен компилятор заниматься.
Имена данных не уникальны на уровне модулей. Но модули обмениваются ими на уровне ссылок. Опять же: нет никаких проблем с этим.

Запись от CoderHuligan размещена 14.02.2024 в 13:34 CoderHuligan вне форума

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

Запись от CoderHuligan размещена 14.02.2024 в 13:49 CoderHuligan вне форума

Сообщение от CoderHuligan

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

Кто вам это сказал?
ВЫ проводили масштабный опрос на эту тему или так думаете?

Сообщение от CoderHuligan

Потому что надо понимать системы. Ну давайте писать для каждой функции предваряя её имя информацией в каком файле она находится с полным путем. Понравится такое читать? Да никому. А неймспейсы это тоже самое на уровне всех имен..

1 Это не одно и тоже
2 Что со мной не так? Что что, а вот нейспейсы не доставляют вообще ни каких сложностей (если, конечно, они не пишутся для каждого класса в каждой строчке (т.е. без использования use)

Сообщение от CoderHuligan

Опять же: нет никаких проблем с этим.

Ну не совсем "компилятор". Просто вы в другой точке будете регистрировать. А я в начале файла добавлю use. При этом сделаю так, чтоб было максимально удобно в контексте данного класса/файла.

Только я в другой проект более спокойно перенесу этот файл, а вы будете методом "научного тыка" искать чего еще незарегистрировали. Разве нет?

Я вообще не понимаю какие проблемы вы нашли в неймспейсах...

Запись от voral размещена 15.02.2024 в 02:20 voral на форуме

Сообщение от CoderHuligan

Ну прям пипец какое усложнение

1 Не нравится поведение возьмите другой ЯП. В PHP echo,print,spritf и тп. в глобальном пространстве

2 И опять же не понял про ошибку при создании подобной. Все ровно точно так же и с неймспейсами. Если создать функцию в области видимости в которой такая уже есть - вызовет ошибку (если, конечно, том контексте не может быть перегрузки)

Сообщение от CoderHuligan

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

Т.е. будет магия ухудшающая отладку. Скажем "переименовла" ваша система создав алиас. автоматически. Но разработчик об этом ни чего не знает. И, особенно если в проекте нужны обе реализации, хрен он угадает какая функция будет вызвана.

Кроме того, код станет на много сложнее выглядеть. т.к. вместо

Code
1
2
a=sqrt(10);
print(a);

будет

Code
1
2
emit('sqrt',a,10);
emit('print',a);

т.е. даже на таком простеньком примере мы уже видим
1 серьезная потеря читабельности
2 дополнительные расходы процессорного времени
3 Это еще не учитываем то, что есть только один глобальный неймспейс. и при этом вы вынуждены будете придумывать длинные имена функциям. ибо может быть такая ситуация в рамках одного кода

Code
1
2
3
emit('sqrt',a,10);
emit('print',a);
emit('print',a);

Что в этом коде не так? Заметили? Удобно читать?

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

При этомвсе ради непонятно чего т.к. по сути ни чего не изменилось: в обоих случаях мы вызываем некие функции просто разный синтаксис. Плюс, в вашем случае, под капотом это прогоняется через дополнительную сущность. Хотя вообще ни чего не мешает, оставив "мой" синтаксисис, под капотом компилятора/интерпретатора использовать хоть событийную модель хоть какую.

Запись от voral размещена 15.02.2024 в 08:14 voral на форуме

2 из 4

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Web (WebAssembly): Реализация движения на Box2D v3 - трение и коллизии с повёрнутыми стенами 8Observer8 20.02.2026 Содержание блога Box2D позволяет легко создать главного героя, который не проходит сквозь стены и перемещается с заданным трением о препятствия, которые можно располагать под углом, как верхнее. . .	Конвертировать закладки radiotray-ng в m3u-плейлист damix 19.02.2026 Это можно сделать скриптом для PowerShell. Использование . \СonvertRadiotrayToM3U. ps1 <path_to_bookmarks. json> Рядом с файлом bookmarks. json появится файл bookmarks. m3u с результатом. # Check if. . .	Семь CDC на одном интерфейсе: 5 U[S]ARTов, 1 CAN и 1 SSI Eddy_Em 18.02.2026 Постепенно допиливаю свою "многоинтерфейсную плату". Выглядит вот так: https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11617&stc=1&d=1771445347 Основана на STM32F303RBT6. На борту пять. . .	Камера Toupcam IUA500KMA Eddy_Em 12.02.2026 Т. к. у всяких "хикроботов" слишком уж мелкий пиксель, для подсмотра в ESPriF они вообще плохо годятся: уже 14 величину можно рассмотреть еле-еле лишь на экспозициях под 3 секунды (а то и больше),. . .
И ясному Солнцу zbw 12.02.2026 И ясному Солнцу, и светлой Луне. В мире покоя нет и люди не могут жить в тишине. А жить им немного лет.	«Знание-Сила» zbw 12.02.2026 «Знание-Сила» «Время-Деньги» «Деньги -Пуля»	SDL3 для Web (WebAssembly): Подключение Box2D v3, физика и отрисовка коллайдеров 8Observer8 12.02.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами и вызывать обработчики событий столкновения. . . .	SDL3 для Web (WebAssembly): Загрузка PNG с прозрачным фоном с помощью SDL_LoadPNG (без SDL3_image) 8Observer8 11.02.2026 Содержание блога Библиотека SDL3 содержит встроенные инструменты для базовой работы с изображениями - без использования библиотеки SDL3_image. Пошагово создадим проект для загрузки изображения. . .

Сообщение форума

Отменить изменения