PHP и структуры

Гарантирование типа - не является задачей структуры, это задача ЯП. Задача структуры - гарантирование полей.
Для чего она нужна? Я вот тоже не знаю, для чего она нужна, не я хотел ее тут В разных ЯП структура играет разную роль. В с++ - структура фактически синоним класса и играет скорее семантическую разницу. В с# структура тоже близко к классу, но отличий несколько больше, основное, что структура передается по значению, тогда как объект класса - по ссылке. В Java нет отдельной конструкции "структура".

 

Все в пхп есть, что нужно динамически типизированному языку. И гарантирование структуры и проверка типа объекта.
Структура в пхп может и была полезна кому-то в том виде, что придумано в c#, но сильного прорыва и профита в этом не вижу...

 

Ну скажи, в каком языке структуры - "более легкая версия".

 

В го же нет объектов, как и в сях, какое там различие может быть? Object.h в сях - это просто надстройка на структурах.

 

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

 

PHP:

1. final class struct {
2.  
3.     private $_key,
4.             $_value,
5.             $_callback;
6.  
7.     public function __construct($key, $value, callable $callback) {
8.         $this->_key = $key;
9.         $this->_value = $value;
10.         $this->_callback = $callback;
11.     }
12.  
13.     public function __call($call, array $args) {
14.         if(isset($this->{'_' . $call}) && ($call = $this->{'_' . $call}) && is_callable($call)) {
15.             return call_user_func_array($call, $args);
16.         }
17.     }
18.  
19.     public function __get($key) {
20.         if(isset($this->{'_' . $key})) {
21.             return $this->{'_' . $key};
22.         }
23.     }
24.  
25.     public function __set($key, $value) {
26.         return;
27.     }
28.  
29. }

PHP:

1. $s = new struct('name', 'value', function() {
2.     return __FUNCTION__;
3. });
4.  
5. $s->key = 1; // игнор
6. $s->value = 2; // игнор
7. $s->calback = function() {
8.     return'implemented';
9. }; // игнор
10. $s->newVar = 'new'; // игнор
11.  
12. echo $s->key, // name
13. $s->value, // value
14. $s->callback(); // {closure}

 

Ну-ну и как же ты интересно инкапсулируеш массив или stdClass? И каллбеки еще введи туда ага. Ты подумал бы прежде чем писать.

 

Существует пхпдок

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

 

Остается застрелиться.

 

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

Ты хочешь сказать. что:
Наполнение stdClass, будет меньше весить, чем наполнить $array[] ?
Я не так давно сделал, чтобы у меня объекты сохранялись - взбрело в голову, чтобы на этапе выполнения программы, по надобности можно было делать export или import, как объектов, так и массивов, но все равно массивы работают быстрее, а вот на том, что весят больше, надо будет как-нибудь на досуге проверить на реальных данных.

 

Смотрел, но пока сам не убежусь и не протесчу на реальных данных, а не каких-то гонимых циклах в 1000 - 100000 (циферок).

Вообщем Массивы:
73 ms, 20.6 mib

Объекты:
87 ms, 20.75 mib

Но пока я на реальных данных не проверю, хер поверю, что такое возможно.

 

В поддержку. При работе с объектами есть один косяк - ссылки, по которым они передаются. Если за этим не проследить, то на больших объемах сборщик мусора перестает разбираться в этой мешанине, начинает халявничать и память течет. Это конечно же вопрос к качеству кода, но всё же дополнительная сложность.

 

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

У тебя есть реалный кейс? Ты нашел причину? Можно почитать открытый баг?

 

Дык это не баг ни разу. Объекты, если их не клонировать, передаются ссылками, ссылки эти могут остаться где-то в недрах того же orm от фреймворка и потекло. Сборщик это видит и соответственно удалить не может. Да и не рассчитано оно на это. Массив же штука простая, область видимости пропала - можно удалять. Я ж написал, что это вопрос к качеству кода, а не к пыху и его сборщику )

можно. Если это не долгоживущее cli.