[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Нужен совет по написанию функции
Zenith
Написал функцию совмещающую serialize() и unserialize().

function obseser($a){
if(is_string($a)){
$a=unserialize($a);
return $a;
}elseif(!is_string($a)){
$a=serialize($a);
return $a;
}
return false;
}


Проблема в том, что если функция принимает простую строку с текстом "Привет, мой пушистый друг!", то возвращает пустую переменную.
Другими словами подскажите, как можно проверить, что входящая строка не произвольный набор символов, а имеет вид:
a:1:{i:0;s:26:"Привет, мой пушистый друг!";}




Спустя 7 минут, 14 секунд (6.10.2010 - 10:45) waldicom написал(а):
Так тут в коде получается, что когда на вход приходит строка, то функция пытается сделать из нее unserialize, хотя это простая строка. Наверняка надо как-то переделать функцию.

Спустя 2 часа, 44 минуты, 33 секунды (6.10.2010 - 13:30) arvitaly написал(а):
<?php

try

{
set_error_handler('new_error_function', E_ALL);

$a='a:1:{i:0;s:26:"Привет, мой пушистый друг!";}';

$b='Привет, мой пушистый друг!';

print_r(obseser($a));

print_r(obseser($b));

}
catch (Exception $e)
{
die ($e->getMessage());
}
function obseser($a)
{
return is_string($a) ? unserialize($a) : serialize($a) ;
}
function new_error_function ($code, $str, $file, $line)
{
if ($code == 8)
{
throw new Exception ("Ошибка! На вход функции десериализации подали неверный параметр.");
}
}


Можно так попробовать

Спустя 25 минут, 29 секунд (6.10.2010 - 13:55) arvitaly написал(а):
+ можно еще дополнительную проверку ввести, но она такая вспомогательная

function obseser($a)
{
return is_string($a) ? ( preg_match("~^(i|s|a|o|d):(.*);~Usi",$a) ? unserialize($a) : false ) : serialize($a) ;
}

Спустя 7 минут, 25 секунд (6.10.2010 - 14:03) linker написал(а):
А что будет если написать
obseser(true);

Спустя 9 минут, 31 секунда (6.10.2010 - 14:12) arvitaly написал(а):
Объект (по-сути, значение типа boolean) сериализуется и мы справедливо получим «b:1;»

Спустя 14 минут, 13 секунд (6.10.2010 - 14:26) linker написал(а):
Все, я заработался, пора отдыхать.

Спустя 9 часов, 22 минуты, 21 секунда (6.10.2010 - 23:49) Zenith написал(а):
Спасибо, народ!
Пойду раскуривать ваш код. smile.gif

Спустя 1 час, 31 минута (7.10.2010 - 01:20) twin написал(а):
arvitaly
Цитата
Можно так попробовать
+ можно еще дополнительную проверку ввести, но она такая вспомогательная

О, Боги!
Ну куда ж такую городушку то...
С ума с этим ООП посходили все.
    function obseser($a)
{
return @unserialize($a) ? unserialize($a) : serialize($a);
}


$array = array("Привет, мой пушистый друг!");
$string = 'a:1:{i:0;s:47:"Привет, мой пушистый друг!";}';

var_dump(obseser($array));
var_dump(obseser($string));

Спустя 9 минут, 22 секунды (7.10.2010 - 01:29) arvitaly написал(а):
<?php    
function
obseser($a)
{
return @unserialize($a) ? unserialize($a) : serialize($a);
}


$array = array("Привет, мой пушистый друг!");
$string = serialize($array);
$str = "Привет, мой пушистый друг!";
var_dump(obseser($array));
var_dump(obseser($string));
var_dump(obseser($str));


Насколько я понял ТС нужно, чтобы 3 пример выдавал ошибку а не сериализовал строку

Спустя 28 минут, 20 секунд (7.10.2010 - 01:57) twin написал(а):
Про ошибку ничего не говорилось. А серелизовать можно все, что угодно, кроме ресурсов, что собственно мы и наблюдаем в коде топикстартера.
Ну а если уж следовать такой логике, что нужна ошибка, то так хотя бы:
    function obseser($a)
{

if(@unserialize($a))
return unserialize($a);
elseif(is_object($a) || is_array($a))
return serialize($a);
else
return
false;
}


$array = array("Привет, мой пушистый друг!");
$string = serialize($array);
$str = "Привет, мой пушистый друг!";

var_dump(obseser($array));
var_dump(obseser($string));
var_dump(obseser($str));

Спустя 3 минуты, 26 секунд (7.10.2010 - 02:01) arvitaly написал(а):
Лично мое мнение - заглушки это не выход и использовать их можно только во время отладки, так как они блокируют все возможные ошибки, а не только ту которую мы ожидаем

Спустя 6 минут, 7 секунд (7.10.2010 - 02:07) twin написал(а):
Заглушка - еще какой выход. Если её с умом применять. Бывают варианты, где без неё практически невозможно обойтись. Ну и вот в таких случаях. Чем городить такой огород, достаточно поставить маленькую собачку.

Ничего она не испортит. И блокирует не ошибку в данном случае, а вывод её на экран (или лог).

Логика простая до безумия - смогла справится функция с задачей, значит поручим ей. Не смогла - не судьба.

Исключения кстати делают тоже самое, только код попахивает индуаизмом.

Спустя 9 минут, 38 секунд (7.10.2010 - 02:17) arvitaly написал(а):
Цитата
Заглушка - еще какой выход. Если её с умом применять. Бывают варианты, где без неё практически невозможно обойтись.


Можно пример?

Функция может не работать по разным причинам и если мы ставим заглушку - с вероятностью 30% мы этого даже не заметим. Ошибок либо быть не должно, либо мы должны знать о них все.

Спустя 1 час, 20 минут, 41 секунда (7.10.2010 - 03:37) twin написал(а):
Ну отчасти я согласен, строить логику на ошибках не очень то красиво, сам всегда ругаюсь.
Но тут в любом случае этого избежать сложно. try... catch - та же самая логика на ошибках.
Если бы была функция is_serialize() к примеру, конечно о заглушках не стоило бы думать))

А вот с этим
Цитата
Ошибок либо быть не должно, либо мы должны знать о них все.
я полностью согласен. Но. Никому не интересно видеть на экране
Цитата
"Ошибка! На вход функции десериализации подали неверный параметр."

Это из оперы or die(). И по этой причине я никогда не использую исключения.
Для дебаггинга слишком громоздко, а в рабочем приложении ему вообще не место. Логируются ошибки и без того легко и просто.

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

Собственно получается очень короткая запись исключения.

А пример... Где то у Котерова видел оригинальный код, где без собаки никак.
Будет время - поищу.

Спустя 35 минут, 2 секунды (7.10.2010 - 04:12) arvitaly написал(а):
Основная идея там перехват всех фатальных ошибок и предупреждений. И совершенно необязательно выводить на экран die (я лично ее ни в одном скрипте не использую), можно писать в лог-файл ошибок, а на экран вывести чтонить типа "Сервер недоступен" и послать письмо админу. А использовать исключения или нет - это лично дело каждого ( я не призываю smile.gif, здесь я их вообще для разнообразия использовал ).

В этом случае с unserialize все так соглашусь, может быть и возможно использовать заглушку, но это скорее исключение из правил - ТС почему то ожидает на вход именно неверные строки (что скорее всего говорит о неправильном подходе к задаче, так как вряд ли сериализационные объекты он берет со стороны)

Спустя 3 часа, 58 минут, 24 секунды (7.10.2010 - 08:11) linker написал(а):
twin
Извини, но я тебя не узнаю
return @unserialize($a) ? unserialize($a) : serialize($a);
Двойной unserialize учитывая, что если попадется большущий массив, а данная функция работает ну очень медленно (причем serialize работает гораздо быстрее), мы потеряем в производительности просто афигеть как.

Спустя 39 минут, 42 секунды (7.10.2010 - 08:50) kirik написал(а):
Вот вы мутки мутите тут smile.gif

Цитата (linker @ 7.10.2010 - 00:11)
Двойной unserialize учитывая, что если попадется большущий массив, а данная функция работает ну очень медленно (причем serialize работает гораздо быстрее), мы потеряем в производительности просто афигеть как.

Это еще пол беды - можно решить как-нить так:
function obseser($a)
{
return ($return = @unserialize($a)) ? $return : serialize($a);
}

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

Задача интересна, подумать нада.. А ТС посоветую не писать универсальностей - они расхолаживают. Ибо ты точно должен знать в какой части программы какие данные ты получаешь (или ожидаешь получить).

ЗЫ.
как временная мера - можно прилепить заплатку ввиде $a !== false && ..

Спустя 19 минут, 33 секунды (7.10.2010 - 09:10) twin написал(а):
kirik, привет. Сто лет, сто зим. smile.gif


А вот так если, то все пучком:
    function obseser($a)
{
if($b = @unserialize($a))
return $b;
else
return
serialize($a);

}

Ну или добавить условий, если ошибка нужна:
    function obseser($a)
{
if($b = @unserialize($a))
return $b;
elseif(is_array($a) || is_object($a))
return serialize($a);
else
return
false;

}


По крайней мере это круче исключений. По производительности кстати тоже. про Читабельность вообще молчу)))

Спустя 15 минут, 30 секунд (7.10.2010 - 09:25) twin написал(а):
kirik опередил smile.gif
Цитата
если в эту функцию передать false то функция уже никак не годна для производства

почему?

Спустя 3 часа, 17 минут, 24 секунды (7.10.2010 - 12:43) arvitaly написал(а):
Цитата
По крайней мере это круче исключений. По производительности кстати тоже. про Читабельность вообще молчу)))


Давайте голословно не будем высказываться.

Цитата
elseif(is_array($a) || is_object($a))


Почему только массив или объект?

Спустя 1 час, 55 минут, 22 секунды (7.10.2010 - 14:38) twin написал(а):
Цитата
Давайте голословно не будем высказываться.

Соглашусь. Не по всам критериям круче. Если брать во внимание то, что иногда лучше написать много строк кода (индийский подход к оценке качества), то да. Тут конечно лучше облепить код ексепшенами.
Солидно и грозно. Для непосвященных.

Цитата
Почему только массив или объект?
Я же написал - если нужна ошибка. Я понятия не имею, что собирается обрабатывать этой функцией топикстартер. Судя по его коду - все подряд.
Это просто пример, как сделать то же исключение.

Спустя 4 минуты, 20 секунд (7.10.2010 - 14:43) arvitaly написал(а):
Цитата
Соглашусь. Не по всам критериям круче. Если брать во внимание то, что иногда лучше написать много строк кода (индийский подход к оценке качества кода), то да. Тут конечно лучше облепить код ексепшенами.
Солидно и грозно. Для непосвященных.


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

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

Т.е. было 18 функций для обработки ошибок стало 2 класса с набором методов (причем уже многое унаследованно с базового класса).
Ребята из PHP-Zend разрабатывают язык для улучшения производительности программиста, так к чему это игнорировать

Я вообще больше интересовался про производительность и читабельность.

Спустя 59 минут, 21 секунда (7.10.2010 - 15:42) twin написал(а):
Цитата
Ребята из PHP-Zend разрабатывают язык для улучшения производительности программиста
Каждый сходит с ума по своему...
Потом из-за этих благих намерений вот такие темы рождаются.

Спустя 4 минуты, 19 секунд (7.10.2010 - 15:46) arvitaly написал(а):
Цитата
Каждый сходит с ума по своему...
Потом из-за этих благих намерений вот такие темы рождаются.


Какой смысл использовать язык - создатели которого сошли с ума? smile.gif

Спустя 9 минут, 53 секунды (7.10.2010 - 15:56) twin написал(а):
Ты попутал))) Это не создатели, а разработчики. Совершенно разные вещи.
Создавался язык для одних целей (даже назывался Personal Home Page), а теперь из него делают непонятно что.
Причем совершенно не надо путать в одну кучу разработчиков языка и фреймворка.
Язык развивается - хорошо. Но концепция у него изначально иная, нежели лепить монструозные программы, прикрываясь благими намерениями.

Если хочется ООП - в питон пожалуйста. Куда как круче. Или рельсы.

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

А разработчики этому потакают. И зря. Лучше бы функционал улучшали.

Вон, функции is_serialize() - нету. biggrin.gif

Спустя 7 минут, 41 секунда (7.10.2010 - 16:04) arvitaly написал(а):
Цитата
Но концепция у него изначально иная, нежели лепить монструозные программы, прикрываясь благими намерениями.


Согласен, изначально язык писался для людей, которые не хотят учить "сложный" c++, зато хотят писать простенькие сайты, которые пишутся одним - двумя "человеками" максимум несколько дней.

Но время как бы идет и на PHP пишутся реально огромные проекты, в которых ну никак не обойтись без MVC, SVN, ООП и т.д. (сколь бы заумно эти слова не звучали).

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


Цитата
Вон, функции is_serialize() - нету. 


Думаю, это связано с тем, что такая функция требовала бы ресурсов чуть меньше чем unserialize, так как абсолютно также пришлось бы обрабатывать всю строку

Спустя 4 минуты, 21 секунда (7.10.2010 - 16:08) twin написал(а):
Цитата
И если начинающий программист хочет хоть куда вырасти - ему стоит привыкать к условиям разработки серьезных проектов сразу.

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

PS
Цитата
Думаю, это связано с тем, что такая функция требовала бы ресурсов чуть меньше чем unserialize, так как абсолютно также пришлось бы обрабатывать всю строку

Это шутка была (с) smile.gif

Спустя 45 минут, 34 секунды (7.10.2010 - 16:54) arvitaly написал(а):
Просто приведу пример. Задача - получить корень числа
1. ООП
class Math
{
public static function Multiply($a, $b)
{
return $a * $b;
}
public static function Addition()
{
return $a + $b;
}
public static function Subtraction()
{
return $a - $b;
}
public static function Division()
{
return $a / $b;
}
private static function _Pow($a, $b)
{
return pow($a,$b);
}
public static function Square($a)
{
return self::_Pow($a,0.5);
}
}

Этот код в каких то там файлах, я даже не знаю в каком файле и понятия не имею что в нем. Зато я знаю, что у меня есть класс, в котором есть математические функции (даже из названия).

Я в редакторе набираю Math:: и получаю список доступных методов, выбираю мне нужный и использую

echo Math::Square(25);


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

Спустя 24 минуты, 7 секунд (7.10.2010 - 17:18) twin написал(а):
Цитата
Этот код в каких то там файлах, я даже не знаю в каком файле и понятия не имею что в нем.

Вот я и говорю - потом такие темы рождаются. biggrin.gif Если даже ты нихрена не знаешь, как последователю то узнать?

Горе от ума.

Спустя 4 минуты, 26 секунд (7.10.2010 - 17:22) arvitaly написал(а):
Цитата
Если даже ты нихрена не знаешь, как последователю то узнать?


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

В этом и заключается суть ООП - многократное ускорение кодинга, возможность разработки кода даже неизвестными людьми, возможность улучшать отдельные части не затрагивая весь проект (в моем случае нужно только добавить 1 метод в класс, а в вашем нужно запомнить 1000+1 функцию)

Спустя 25 минут, 23 секунды (7.10.2010 - 17:48) twin написал(а):
Цитата
(в моем случае нужно только добавить 1 метод в класс, а в вашем нужно запомнить 1000+1 функцию)

да кто же сказал тебе таких глупостей?

1000+1 метод запоминать не надо разве?
Цитата
А последователь вообще вникнет в суть пробежавшись глазами по описанию списка классов.

Или кто-то запретил документировать процедурку? Только ООП можно документировать?

А я вот так скажу. Ты вызываешь класс. Он подгружается автолоадером. Так? Так. Или нет?

Так вот. Ты пишешь так:
$obj = new SuperClass();
$var = $obj -> method();

И считаешь что ускорил разработку. А чем? Я вот напишу так:

    include_once './libs/functions.php';
$var = method();

И что? Действия те же, то же подключение. Только легче - без кучи оберток.
Строк так же две.
Только в моем случае сразу видно где находится - раз, можно хранить в разных папках - два. А это структурность. При автолоаде все классы (1000+1) должны находиться в одной папке. Ищи-свищи. А найдешь, так там еще куча мусора, ООП код полюбому избыточнее процедурки. Сия тема - яркое подтверждение.

Если тебя пугает конфликт имен - хрень. Надуманная проблема. Нет её вовсе при модульной структуре. Если ты сейчас начнешь мне в уши дуть про кучу разработчиков - не надо. Это просто решается префиксами.

И вообще. Всегда говорят, как самый незыблимый аргумент - вот я раньше писал процедурно, теперь научился писать на ООП и это круче. Сам попробуй - поймешь.

Я так скажу. Когда после ООП научишься писать действительно нормальный процедурный код, тогда только поймешь разницу.

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






Спустя 37 минут, 36 секунд (7.10.2010 - 18:25) arvitaly написал(а):
Цитата
1000+1 метод запоминать не надо разве?


Нет, разница в том, что любая среда разработки PHP сможет сама подсказать все функции класса. А вот об ИИ, который бы находил из 1000 функций нужную я не слышал. А, как я уже говорил основная задача ООП - ускорить процесс выпуска готового продукта.

Цитата
Только в моем случае сразу видно где находится - раз, можно хранить в разных папках - два. А это структурность. При автолоаде все классы (1000+1) должны находиться в одной папке.


Чушь, совершенно необязательно хранить все в одной папке, прошу не писать о чем не знаете.
Цитата
Ищи-свищи. А найдешь, так там еще куча мусора, ООП код полюбому избыточнее процедурки. Сия тема - яркое подтверждение.


Пустые слова - какая то куча мусора, какое то подтверждение.


Цитата
Если тебя пугает конфликт имен - хрень. Надуманная проблема. Нет её вовсе при модульной структуре. Если ты сейчас начнешь мне в уши дуть про кучу разработчиков - не надо. Это просто решается префиксами.


Ну да вначале были префиксы, но потом люди постепенно поняли, что бездумное

db_funtion1
db_function2
db_function3
$db_var1

гораздо эффективнее заменить на общий объект db, который будет содержать в себе все эти методы+переменные+константы. Так появлялось ООП.



Цитата
И вообще. Всегда говорят, как самый незыблимый аргумент - вот я раньше писал процедурно, теперь научился писать на ООП и это круче. Сам попробуй - поймешь.


Во 1 я такого не говорил.
Во 2 я писал и так и так и сейчас иногда (редко) пишу без ООП - но исключительно отдельные одноразовые скрипты, когда действительно в разработку структуры ООП уйдет больше времени. Но речь идет о проектах.

Цитата
Я так скажу. Когда после ООП научишься писать действительно нормальный процедурный код, тогда только поймешь разницу.


Т.е. по вашему мнению любой оппонент априори не умеет писать нормальный процедурные код? Что-то типа: "Весь мир дураки - используют ООП, а даже не попробовали писать нормальный процедурный код".


Цитата
Сейчас ты пытаешься сравнить ООП с говнокодингом. Невольно причисляя меня к его последователям.


Да нет именно с приведенным вами кодом и пытаюсь сравнивать. Не знаю говнокод он или нет по вашему мнению.


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


В 10 веке люди вообще точно знали, что земля круглая. Я привел пример эффективности даже без задницы, а вы можете?

Спустя 1 час, 1 минута, 56 секунд (7.10.2010 - 19:27) twin написал(а):
Цитата
Нет, разница в том, что любая среда разработки PHP сможет сама подсказать все функции класса.

Да ладно, позволяет))). Любая среда разработки (не только php) позволяет найти все что угодно в файле, если я сразу вижу где искать.
Везде есть системы поиска.
Мне даже среда не нужна, я могу и в блокноте работать (если прижмет) со своей структурой. Прямо с телефона. Все перед глазами. Файл - функция.

Цитата
А, как я уже говорил основная задача ООП - ускорить процесс выпуска готового продукта.

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

Цитата
Пустые слова - какая то куча мусора, какое то подтверждение.

Да как же так? Почему вы все не видите очевидного то? Ну с этим то спорить просто глупо. Неужели это:
try
{
set_error_handler('new_error_function', E_ALL);

$a='a:1:{i:0;s:26:"Привет, мой пушистый друг!";}';

$b='Привет, мой пушистый друг!';

print_r(obseser($a));

print_r(obseser($b));

}
catch (Exception $e)
{
die ($e->getMessage());
}
function obseser($a)
{
return is_string($a) ? unserialize($a) : serialize($a) ;
}
function new_error_function ($code, $str, $file, $line)
{
if ($code == 8)
{
throw new Exception ("Ошибка! На вход функции десериализации подали неверный параметр.");
}
}
смотрится компактнее этого:
    function obseser($a)
{
if($b = @unserialize($a))
return $b;
elseif(is_array($a) || is_object($a))
return serialize($a);
else
return
false;

}
Какие пустые слова? Любой класс по определению избыточнее набора функций. А если еще интерфейсами обляпать - вообще капец.
Как об стену горох...

Цитата
гораздо эффективнее заменить на общий объект db, который будет содержать в себе все эти методы+переменные+константы. Так появлялось ООП.
Не эфетивнее. Вот в чем дело то. Это на первый взгляд упрощает разработку, а на самом деле только путает все. Повторю - при нормально структурированном модульном императивном коде конфликтов имен не возникает.
Без префиксов. Это тоже самое, что бояться конфликта имен в рамках одного класса.

Цитата
Что-то типа: "Весь мир дураки - используют ООП, а даже не попробовали писать нормальный процедурный код".
Далеко не так))) С точностью до наоборот. Я лично знаю многих программистов, отказавшихся от этих забав в пользу естественного для PHP процедурного (вернее смешанного) кодинга. Классы и я с удовольствием использую. Но только там, где им действительно место. Не строя воздушных замков из наследований и полиморфизма. Кстати, вот полюбопытствуй. Забугорный автор пишет, это к вопросу о всем мире. biggrin.gif

Цитата
В 10 веке люди вообще точно знали, что земля круглая.

Ну да. Думали. А еще думали раньше, что реки хорошо бы вспять повернуть. Слава те - одумались. Людям вообще свойственно ошибаться.
Цитата
Я привел пример эффективности даже без задницы, а вы можете?
Да ешкин кот... Где же там эфективность то? Через задницу и есть.
Единственный плюсик на этапе разработки, который тянет за собой кучу проблем.
Я вот спокойно обхожусь без этих наваротов, но спасибо за идею. Написать такую утилитку на сишке, которая выдаст список функций в файле (по названию которого math.php так же можно понять принадлежность) не такая уж задача smile.gif
Может кстати и есть все это уже.









Спустя 14 минут, 22 секунды (7.10.2010 - 19:42) arvitaly написал(а):
Цитата
Да ладно, позволяет))). Любая среда разработки (не только php) позволяет найти все что угодно в файле, если я сразу вижу где искать.
Везде есть системы поиска.
Мне даже среда не нужна, я могу и в блокноте работать (если прижмет) со своей структурой. Прямо с телефона. Все перед глазами. Файл - функция.


Противоречие самому себе. В чем отличие классов от ваших файлов, кроме того, что еще надо писать

include ("functions1.php");
include ("functions2.php");
include ("functions3.php");

и так для всех.

Цитата
Вот вот. В сотый раз повторяюсь - взяли моду думать так. Что самое главное, это комфортные условия для разработчика. А то, что поддерживать потом кому то придется, вообще никого не колышит.

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

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


Ссылки - это аргументы?

Цитата
Да как же так? Почему вы все не видите очевидного то? Ну с этим то спорить просто глупо. Неужели это:


Я уже писал, что для отдельно взятого небольшого скрипта (как в данном случае) без ООП действительно можно обойтись, но надо четко понимать это и рассматривать проект в целом, а не по кусочкам.

Цитата
Какие пустые слова? Любой класс по определению избыточнее набора функций. А если еще интерфейсами обляпать - вообще капец.
Как об стену горох...


Можно пример


Цитата
Повторю - при нормально структурированном модульном императивном коде конфликтов имен не возникает.
Без префиксов.


1000 уникальных имен функций? Мда, таким макаром можно один проект 100 лет делать - заниматься только тем, чтобы сидеть и придумывать уникальные имена функциям, чтобы не было конфликтов.


Цитата
Далеко не так))) С точностью до наоборот.

Цитата
И вообще. Всегда говорят, как самый незыблимый аргумент - вот я раньше писал процедурно, теперь научился писать на ООП и это круче. Сам попробуй - поймешь.

Я так скажу. Когда после ООП научишься писать действительно нормальный процедурный код, тогда только поймешь разницу.


Цитата
Ну да. Думали. А еще думали раньше, что реки хорошо бы вспять повернуть. Слава те - одумались. Людям вообще свойственно ошибаться.


Хорошо, что одумались не во всем - иначе мы бы щас до сих пор посыльных с письмами гоняли.

Цитата
Не строя воздушных замков из наследований и полиморфизма.


Блин, кто тут говорил о говнокодинге? Да можно испортить что угодно и что?

Цитата
Единственный плюсик на этапе разработки, который тянет за собой кучу проблем.


Каких проблема, просил же без голословности.

Цитата
Я вот спокойно обхожусь без этих наваротов, но спасибо за идею. Написать такую утилитку на сишке, которая выдаст список функций в файле (по названию которого math.php так же можно понять принадлежность) не такая уж задача 
Может кстати и есть все это уже.


Ну велосипед изобретать вообще модно

Спустя 45 минут, 39 секунд (7.10.2010 - 20:27) twin написал(а):
Цитата
Противоречие самому себе. В чем отличие классов от ваших файлов
отличие в том, что видно путь, где он лежит.

Цитата
Не вижу логики, кого не колышит, я по моему писал что даже последователям намного удобнее, когда даже среда разработки подсказывает, что лучше использовать.
Это далеко не так. И известно мне не понаслышке. Я долгое время занимался рефакторингом. Логику ООП проследить гораздо сложнее.

Цитата
Ссылки - это аргументы?
Аргумент не сама ссылка, а её содержимое. И это - аргумент. Чего тут не понятного то?

Цитата
Можно пример
ты сам написал про матиматику. Убери класс и сравни.

1000 уникальных имен функций? 
На кой ляд? Самому не смешно? smile.gif
Где это видано в одном модуле 1000 функций? Что это за проект такой?
Я же говорю - при правильной структуризации никаких конфликтов не будет.

Цитата
Каких проблема, просил же без голословности.

Да какая голословность то? Я сколько могу повторять одно и тоже. Это не только мое мнение.

ООП структура менее прозрачна и более ресурсоемка, нежели процедурная. Отсюда и проблемы с рефакторингом, поддержкой и эксплуатацией.

Выгода только на этапе разработки.

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

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

Я никого не переубеждаю. Просто заводит, когда люди не видят очевидного.

Цитата
Ну велосипед изобретать вообще модно

Мое любимое занятие. Нетерплю, когда меня под ранжир суют.





Спустя 8 минут, 54 секунды (7.10.2010 - 20:36) arvitaly написал(а):
Цитата
Я никого не переубеждаю.


smile.gif

Цитата
Я могу сравнивать. ты нет.


Все дураки - один я умный.

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

Спустя 11 минут, 28 секунд (7.10.2010 - 20:48) twin написал(а):
Цитата
Все дураки - один я умный.

Нууууу. Я не говорил такого. Не нужно причислять себя ко всем. И ко всему миру тем более. smile.gif Слишком громко это будет.
Я констатировал факт просто. Из твоих слов:
Цитата
я писал и так и так и сейчас иногда (редко) пишу без ООП - но исключительно отдельные одноразовые скрипты, когда действительно в разработку структуры ООП уйдет больше времени. Но речь идет о проектах.
Раз ты считаешь, что проекты писать иначе нельзя, значит и сравнить тебе не с чем. А я вот пишу. И сравниваю.
Цитата
Ладно, все понятно, к счастью весь мир не разрабатывает проекты основываясь на непонятном опыте одного человека...

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


Спустя 17 минут, 37 секунд (7.10.2010 - 21:05) kirik написал(а):
Цитата (twin @ 7.10.2010 - 01:25)
kirik опередил  smile.gif
Цитата
если в эту функцию передать false то функция уже никак не годна для производства

почему?

Передаем в функцию false, получаем b:0;, все верно. Затем передаем сериализованный false в виде b:0;, в ожидании получить обратно свой false, а полуаем непонятные s:4:"b:0;";. Непорядок..
А все потому что функция получив строку b:0; ансериализует ее, и получает false, а так как значение булево, то наше условие начинает обрабатывать serialize($a); кодируя строку b:0;.

Цитата (arvitaly @ 7.10.2010 - 08:54)
Задача - получить корень числа
....
2. Структурное П
Мне нужно из многочисленных функций каким то образом - непонятно каким, непонятно где лежащую - выбрать нужную.

Ага.. давайте теперь на каждую php функцию напишем свою, много своих, потом объеденим это в класс, напишем документацию к классу...итд. Есть абсолютно стандартная функция sqrt().
Нет, я не против ООП, но я против такого подхода как описан выше.

ЗЫ. и вообще, ребят, у топика немного другой заголовок smile.gif Завязывайте спор, а то... забаню! biggrin.gif

Спустя 3 минуты, 20 секунд (7.10.2010 - 21:08) arvitaly написал(а):
Цитата
Ага.. давайте теперь на каждую php функцию напишем свою, много своих, потом объеденим это в класс, напишем документацию к классу...итд. Есть абсолютно стандартная функция sqrt().
Нет, я не против ООП, но я против такого подхода как описан выше.


Вообще то это был пример, ессно никто не собирается засовывать в класс уже готовые PHP-функции (но я был бы только рад если бы в следующих версия они уже были бы обернуты в классы)

Спустя 8 минут, 52 секунды (7.10.2010 - 21:17) kirik написал(а):
Цитата (arvitaly @ 7.10.2010 - 13:08)
Вообще то это был пример

Обычно в примеры дают то, что реально показывает полезность smile.gif

Цитата (arvitaly @ 7.10.2010 - 13:08)
но я был бы только рад если бы в следующих версия они уже были бы обернуты в классы

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

Спустя 8 минут (7.10.2010 - 21:25) arvitaly написал(а):
Цитата
Если человек ни разу не читал мануал по языку, и не знает названий функций, то хоть с классом, хоть без он не будет их знать.


Есть такой язык c# и среда разработки Visual Studio, если не зная никаких функций вбить System.IO.File., то появится список методов класса File с описанием на русском языке. И абсолютно ничего про них не зная можно успешно их использовать, по сути прямо в среде разработки интерактивная документация.

Я больше скажу в Zend Studio - это реализовано точно также.

Спустя 1 час, 7 минут, 29 секунд (7.10.2010 - 22:33) kirik написал(а):
arvitaly
Да какая разница, в какой реализации мануал. Все равно придется искать нужную функцию. PHPмануал вон тоже есть, однако читают его не многие.

Спустя 10 минут (7.10.2010 - 22:43) arvitaly написал(а):
Цитата
Да какая разница, в какой реализации мануал. Все равно придется искать нужную функцию. PHPмануал вон тоже есть, однако читают его не многие.


Ну мы обсуждали тех, кто читает.


_____________
"Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете". (с) Макконнелл, "Совершенный код".
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.