Чушь

Только сейчас задумался об абсурдности кода, например:

PHP:

1.  
2. <?php
3. function foo(Bar $bar = null){
4.     $bar = $bar ? $bar : new Bar();
5.     // ...
6. }
7.  

 

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

Встречается достаточно часто

PS> И вообще, четыре слова "Bar" в одной строке, разделенные непонятными знаками, это вообще круто )

PHP:

1. <?php
2.  
3. $bar = $bar , $bar | $bar & $bar * $bar / $bar // ...
4.  
5.  

 

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

ну да, взамен можно

PHP:

1. <?php function foo($bar = 'bar') ?>

И означать это будет, в переводе на русский язык, что переменной $bar присваивается значение 'bar' если значение переменной не было передано явно.

В общем, не думаю что стоит устраивать полемику и по этому поводу

Simpliest, ты лучше объясни что обозначает одно и то же слово, встречающееся четыре раза в строчке и разделенное разными знаками препинания

UPD>
Ах да, совсем забыл:

PHP:

1. <?php $bar = $bar ?: new Bar(); ?>

Ну да, одна и та же конструкция обозначает разные вещи.

 

[отвлеченно]
Читал Маркуса, где он и группа программистов обсуждали на сорока страницах, стоит ли в интерфейсе объявлять публичные поля объекта

[NeoPHP]
<?neo

function foo($name, $planet = ($planet implements SolarSistem) ? $planet : new ForeignBody::create()->inject($planet)){}
[/NeoPHP]

 

Уместней спросить "сколько работал"

Объект - та же переменная, только с яйцами. У них структура в ZendEngine общая. Конечно, объекты как "тип данных" в терминах Си ушли далеко от простых переменных. Единственная причина, почему нельзя выполнить

Код (Text):

1. function(ZendObject $object = new Object()){}

является тем, что параметры не могут содержать исполняемого кода, а new stdObject и есть исполняемый код.

 

PHP:

1. <?
2.  
3. function bla-bla(){
4.     // ...
5.     if ( var_dump($user->isAuthorize()) ){
6.          // ...
7.     }
8.     // ...
9. }
10.  

 

Simpliest
чтобы по ф5 посмотреть результат возвращаемый функцией, писать на новой строке оказалось лениво

 

PHP:

1.  
2. <?php
3. class Foo
4. {
5.     static $self;
6.  
7.     static public function insatnce(){
8.         // ...
9.         self::$self = new self();
10.         // ...
11.     }
12. }
13.  

PHP:

1. <? self::$self = new self(); ?>

 

Koc
Тебе объяснить зачем запись продублировал, или сам поймешь?

 

+1 Хорошая идея, жаль нельзя, а то бы я ща как развернулся ))

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

Эх

Код (Text):

1. <?neophp
2.     $value = def new Value();
3.  
4.     // ...
5.  
6.     class UserSingletoon realized Singletoon{
7.         // ...
8.     }
9. ?>

 

Продолжу с self-ами:

PHP:

1. <?php
2.     static public function instance(){
3.         if (!self::$self){
4.             self::$self = new self();
5.         }
6.         return self::$self;
7.     }
8.  

 

пишите, Киса

Спасибо, надо бы потихоньку перебираться, а то как ознакомился с пресс-релизом полтора года назад, так до сих пор и не трогал 5.3

никак, проще перейти на C++, либо писать кодогенераторы

 

Volt(220)
не то.

PHP:

1. <?php class DatabaseConnection extends Singleton  ?>

Пока множественного наследования нет, это костыль. Хотя согласен, в 80% случаев этот вариант подходит

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

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

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

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

 

PHP:

1.  
2. <?php
3.  
4.     class AbstractClientSession extends stdSingleton{}
5.  
6.     class UserSession extends AbstractClientSession{}
7.     class GuestSession extends AbstractClientSession{}
8.     class AdminSession extends AbstractClientSession{}
9.  
10.     UserSession::instance()->setRole( new RoleUser(), new RoleGuest() );
11.     GuestSession::instance()->setRole( new RoleGuest() );
12.     AdminSession::instance()->setRole( new RoleUser(), new RoleModerator(), new RoleAdmin());
13.  
14.     // vs <?neophp
15.  
16.     class AbstractClientSession extends stdSingleton{}
17.     class UserSession extends AbstractClientSession realized RoleUser, RoleGuest{}
18.     class GuestSession extends AbstractClientSession realized RoleGuest{}
19.     class AdminSession extends AbstractClientSession realized RoleUser, RoleModerator, RoleAdmin{}
20. ?>
21.  

В реализации есть несущественные отличия, но в первом случае приходится писать рутинную "чушь".

Второй можно оптимизировать по производительности (перекладываем часть логики на Си вместо виртуальной машины zend)
Второй вариант проще воспринимать (имхо)
Второй вариант быстрее написать (не нужно реализовывать механизм делегирование там где этого можно избежать)