Код (Text): ... if ($a == 1){$column = "`a`";} if ($a == 2){$column = "`b`";} if ($column == "`a`" OR $column = "`b`") { $number_1 = "SELECT $column FROM `table` WHERE `id` = ? LIMIT 1"; $number_2 = mysqli_prepare($db,$number_1); mysqli_stmt_bind_param ($number_2,'s', $name); mysqli_stmt_execute($number_2); mysqli_stmt_bind_result($number_2, $id); $number = Array(); for ($p = 0;mysqli_stmt_fetch($number_2);$p++) { $number_[$p]['id'] = $id; } mysqli_stmt_close($number_2); unset($p, $number_1, $number_2, $id); } ... Безопасно ли вышеописанным образом составлять запросы, если заранее неизвестно из какого столбца нужно доставать данные? Так же данный вопрос относится не только к SELECT, но и к UPDATE и INSERT.
1) что сразу используешь mysqli_prepare.. похвально. лучше сразу учиться правильному чем потом переучиваться с mysql 2) вместо OR используй ||. а лучше почитай чем они отличаются и когда. чтоб знать о подводных камнях. на будущее 3) как именно формировать динамический запрос - дело хозяйское. но в приведенном случае логику точно нужно менять. если $a придет со значением 3 например? скрипт будет в неопределенном состоянии. а это небезопасно. логика работы должна обрабатывать как допустимые значения, так и при недопустимых поведение должно быть четко определено. тогда будет ясность. 4) $number_1,$number_2... имена переменным лучше давать осмысленные. в сложных скриптах будет проще ориентироваться. 5) изучи какие есть еще функции. mysqli_fetch_assoc... не придется делать ручками лишней работы. 6) сделай класс-обертку над функциями mysqli_ . в дальнейшем будет проще обслуживать и расширять высокоуровневую функциональность. и при миграции на другие БД поможет.
Приятно читать, что двигаюсь примерно в нужном направлении))) Это про их приоритетность имеется ввиду? У меня на уровень выше стоят ограничения с помощью if/else на $a . Просто не стал выкладывать громоздкий код. У меня переменные с осмысленными именами. Я их в сообщении переименовал для того, чтобы было проще читать. К сожалению пока руки не дошли до более глубокого изучения классов... P.S. Спасибо большое за такой развернутый ответ.
Глубокое изучение классов - это в Си++. В PHP ооп еще примитивное, так что все выучивается и понимается оч быстро.
Моя хотеть множественное наследование и нормальные перегрузки. А еще хотеть не долбаные магические методы, а честное перекрытие системных методов. Хотеть виртуальные классы и виртуальные методы. Хотеть интерфейсы. И еще хотеть нормальные геттер-сеттеры, а не это невероятное УГ, что есть в пыхе сейчас. Но это всего лишь вопрос времени, надеюсь.
1) Я не говорил, что язык плохой, я говорил, что ООП тут пока еще не зрелое; 2) ПХП не ООП язык изначально, так что незрелость ООП не характеризует его как плохой; 3) На плюсах делать веб-проект реально геморнее, угум, да еще и переносимость будет ниже плинтуса; 4) Что за максимализм-то? Указал на косяки != сказал, что все говно, уг, авторам надо застрелиться и все такое
-нафига множественное наследование? приведи РЕАЛЬНЫЙ пример когда тебе это очень нужно подругому никак не сделать? -перегрузки тут ненужны, ибо слабая типизация. не надо хотеть от пхп что он был в точности как Си++. это другой язык. прегрузки тут как пятая нога собаке. для тебя есть примеси. -системные методы? это __toString() и иже сними? -интерфейсы есть, абстрактные классы есть - виртуальные тут не к месту тоже. совсем другая идеология. в общем видно одно - ты перешел в пхп с другого языка(с++ ?), но продолжаешь писать и воспринимать его как другой язык. тоесть на пхп писать неумеешь, так как мыслишь по прежнему совсем в другой плоскости. ум должен быть гибким. нужно уметь писать - используя сильные стороны конкретного языка, а не требовать отнего чтоб он был как {твой_любимый_язык}. если добавить в пхп все о чем ты говоришь - он перестанет быть собой. потеряет гибкость и неповторимость. и будет очередным УГ. ps мне пыхып тоже не нравится местами - но это его особенности. нужно помнить его нишу, для чего вообще он создавался. и не ждать от него того что в него никогда не закладывали и то что там вообще ненужно, ибо этим никто не будет пользоваться. так как тем кому это нужно пишут на других языках, а не ждут когда это появится в пхп)
Ну значит конкретно тебе они не нужны на данном этапе, вот и все Когда упрешься в потребность использовать несколько независимых, но идентичных автономных фрагментов кода, тогда и поймешь суть классов. А пока просто считай, что их нет. Реальный пример - мне нужно было время от времени гибридизировать два функциональных класса. Просто потому что в ряде случаев они дополняют друг друга, в то время как в остальных ситуациях такая конфигурация избыточна. Разумеется, есть альтернативные решения типа как: 1) Создать третий класс, в свойствах которого по объекту первого и второго класса, и проксировать им дергания за методы; 2) Вынести в инклуды все, что хочется гибридизировать и подключать эти части 1 и 2 классов в 3й; А было бы неплохо, будь более естественный вариант - унаследовать третий класс от первых двух. Это ведь в плане реализации не сложнее обычного множественного вертикального наследования, которое в PHP есть. Разработчики боятся, что пхпшники не осилят проблему ромбовидного наследования и выстрелят им себе в ногу? Вряд ли. Тут что-то иное. Ды я бы не сказал. А абстрактные к месту? Чем виртуальные идеологически некорректнее абстрактных, учитывая, что являются их подвидом? Да, перешел и с с++ в том числе, на деле там языков чуть больше, и параллельно юзаются тоже другие. PHP воспринимаю как PHP Но пишу на нем максимально дисциплинированно, что дает свои плоды. Мыслю гибко, чесслово. Та же пхпшная фишка с возможностью самонаписания кода, которая в других языках делается через умораздирающие костыли, мне оч по нраву, и активно юзается. Код, дополняющий и меняющий сам себя - это забавно и круто. Другое дело, что то, что я прошу, не сделает пых хуже. Наоборот, даст ему больше возможностей и больше гибкости. А это вот "оно вам не нужно" - это самообман. Нужно. Просто пока что не реализовано. Но будет, я уверен. Когда-то и половины того ООП не было, что сейчас, и я уверен, что говорили точно так же - "не нужно!". А когда появилось и распробовали, оказалось, что нужно. Просто хочу, чтобы сильных сторон было больше Вряд ли от этого язык станет хуже. Ты же пойми, я не против того что есть. И не говорю, что нужно превращать пых во что-то другое. Он никогда не превратится. Просто в других языках есть решения, которые сделали бы пых только лучше. Я готов отказаться от всех вышеописанных хотелок, но, блджад, кто-нибудь, дайте мне нормальные геттеры-сеттеры и человеческий механизм перегрузок. Слабая типизация? Пффф... Gettype же работает? Работает. В момент времени тип переменной однозначен. Каст происходит только в случае, когда переменная не подходит под контекст. Ну так пусть механизм перегрузок ориентируется на количество и тип именно входящих данных, а не требует их тип от пользователя. Если кого-то это будет смущать, пусть не пользуется и живет как сейчас, делов-то. На эту тему уже было обсуждение. Все это реализуемо. Все это не страшно. Все это в итоге будет удобно и красиво. Не надо бояться новых вещей, которые, по сути своей, давно являются стандартом. Я более чем уверен, что все это в итоге будет сделано.
да не нужно это. ты пойми. функция принимает на вход ВСЕ ЧТО УГОДНО. нет необходимости делать кучу одноименных методов с разными входами. да это отличается от тогоже c++ - ну так в этом и прелесть. руки развязаны. можно делать как угодно. нет рамок как в строгитипизированных яп. и при этом пишутся сложнейшие сайты. строгая типизация помогает компилятору генерить код который быстрее работает, но программисту только лишние ограничения. это не реальный пример! это сферические классы в вакууме. не зная конкретики задачи невозможно указать на варианты реализации, указать на ошибки в структуре и т.д. есть реальные задачи где множественное наследование необходимо. но они лежат вне веба. поэтому давай конкретный реальный пример - тогда можно обсудить. а иначе это словоблудие.
Да да, принимает все что угодно, а ты потом внутри сам определяй, что тебе пришло и делай что хочешь. И плевать на то, что у переменных есть осмысленные имена, которые подразумевают то, что "что угодно" в них писать нельзя, ибо запутаешься. Не гоже в переменную "$name" отдавать дату, а если все именовать $var1,$var2,$var3 - это то еще удовольствие, без доки не понять что вообще куда и как. Это тоже уже обсуждалось. Сейчас работает модель "одна точка входа, тыща ифов/кейсов, тыща реализаций"; Хотя более красивой была бы модель "тыща точек входа, тыща реализаций"; И прелесть в том, что это никак не исключает возможность использования текущей модели. Я не предлагаю отрезать, я хочу, чтобы добавили Пусть пхп разбирается, что там где пришло, а не я это делаю руками, только и всего. И семантика названий переменных будет совпадать с назначением. Все красиво, аккуратно, функционально, и работать будет чуть быстрее за счет нативной реализации. Ды все уже сделано. И архитектура уже изменена. Чтобы достать пример, в котором есть проблема, мне надо физически метнуться в прошлое, потому что это было между коммитами Суть в чем, я повторюсь, я не предлагаю ничего менять. Я перечисляю "хотелки", которые можно добавить не в ущерб тому, что есть. Не понимаю, чего вы так на это реагируете. В пыхе же даже лямбда-выражения есть, хотя они, как и множественное наследование, в 99% случаев нахрен не нужны, и могут быть разрулены другим путем. Но они есть. И позволяют срезать углы. И никто не умер. А кто-то о них даже не догадывается и прекрасно живет.
да нормально реагирую. просто хочется услышать конкретику и обсудить решения. в споре родится(может) истина. уже щас пхп позволяет указывать тип аргументов(класов) если это объекты, массивы и т.д. можно конечно пойти дальше и добавить еще строки, числа ... это даже обсуждалось както. но острой необходимости в этом нет. потому и не добавляют.
А вот гляди, по роду основной деятельности часто приходится работать с такой экзотикой, как MEL. Соль его в том, что там типизация одновременно и строгая и не строгая. То есть если у переменной тип заранее не объявлен, то она мультикастовая, как в пыхе. Если же объявлен, то в нее можно писать только строго то, что она собой являет.Однако для функций всегда строго определен тип возвращаемого значения и входящих данных.
ну есть. и что? на то она и экзотика, потому и такая неопределенность с типизацией. причем тут пыхып? у него как раз все прозрачно и понятно. нужна типизация - есть инструменты приведения, проверки и контроля. не нужна - и не парься - все и так будет работать с полпинка. этой проблемы просто нет(у всех кроме тебя)! понимаешь?)
Времени мало, желания бесплатно делать велосипед с такими большими колесами тоже. ды у меня этой проблемы тоже нет. Это так... Просто оч не хватает перегрузки настоящей. К хорошему быстро привыкаешь и потом его очень не хватает.
воу-воу-воу. потише, чувак. =) Они говорят с тобой? Добавлено спустя 45 секунд: назвать вынужденный костыль хорошим это только переучка-сишник может.
Остроумно. Почитай что ли, что такое хороший тон программирования. Не обсуждай то, что не понимаешь. Вынужденный костыль - это foo($var0,$var1,$var2,$var3,$var4){/* проверка того, что нам пришло в нескольких вариантах и проброс данных в нужную реализацию, вытирая ноги о самого себя, потому что хрен упомнишь, что у тебя где */} Либо хреначить тысячу функций, отличающихся постфиксом в названии, хотя по-хорошему разумнее было бы дать им всем одно имя, даром что делают одно и то же, но разными способами и с разными инпутами, збс чо. Параметры по умолчанию тоже не используешь, ибо ересь, пришедшая из плюсов, которые тебя почему-то пугают? А лямбда-выражения?
считаешь что так будет чем-то лучше? Код (Text): foo(int $var0,Object $var1, String $var2, int $var3,Array $var4) а вообще, если появились такие функции, то действительно есть проблема. но не в языке и его возможностях, а в архитектуре твоего ПО. просто напросто, это значит что функцию уже давно пора рефакторить и дробить на мелкие согласно выполняемым действиям. подумай сам: функция ДЕЛАЕТ ВСЕГДА ОДНО и ТОЖЕ, но с разными входными данными. какой смысл для ОДНИХ и ТЕХ ЖЕ ДЕЙСТВИЙ - создавать кучу одинаковых функций, отличающихся только разным входом? простой пример: функция поиска в списке по переданным ИД - на входе один параметр, НО он может быть числом(один ИД), строкой(ИД перечислены через запятую), массивом с числами(много ИД). т.е. функция ищет в неком ГЛОБАЛЬНОМ списке элементы, где ИД равен тому(тем) что переданы на вход. как Я сделаю это на пхп: Код (PHP): $ITEMS = array(1=>'item1',2=>'item2',...); // пример ГЛОБАЛЬНОГО списка // function getItem($id) { $input = array(); // обработка входных данных, приведение к общему формату(массив с ИД-шниками) if (is_int($id)) { $input[] = $id; } else if (is_string($id)) { $input = explode(',', $id); } else if (is_array($id)) { $input = $id; } else { /* input Error */ } // ОБЩИЙ! алгоритм поиска $out=array(); foreach($ITEMS as $k=>$v) { if (in_array($k,$input)) { $out[$k] = $v; } }//foreach return $out; } как Я сделаю это на c++: Код (PHP): struct ItemMy { // пусть будет такая структура элемента int id; String name; }; // пусть это глобальное хранилище элементов map<int,ItemMy> GLOB; //.. // todo: просто функция заглушка, суть не в ней list<int> strSplit(char delim, String ids){ list<int> out; return out; } // функция поиска если на входе Список ИД list<ItemMy> getItem(list<int> ida) { // вот тут универсальный АЛГОРИТМ ПОИСКА list<ItemMy> out; for( list<int>::iterator it=ida.begin(); it!=ida.end(); ++it ) { int id = (*it); map<int,ItemMy>::iterator it2 = GLOB.find(id); if (it2->first==id) { out.push_back( it2->second ); } }//for return out; } // функция поиска по Входной строке с ИД через запятую list<ItemMy> getItem(String ids) { list<int> ida = strSplit(',',ids); return getItem(ida); } // функция поиска если на входе один ИД - в виде целого list<ItemMy> getItem(int id) { list<int> ida; ida.push_back(id); return getItem(ida); } суть тут не в самой реализации(можно написать и правильнее) а в самом подходе при реализации задачи. используя перегрузку, нам пришлось делать не одну - а ТРИ функции, это минимум. функционал "размазан" по большому куску кода. кода в итоге написать пришлось больше. дополнительных плюсов - никаких.
.NET, к примеру, весь на перегрузках и это оч удобно. Погляди хотя бы на MessageBox.show(); Перегрузка - не инструмент построения архитектуры. И не инструмент решения архитектурных задач. Это инструмент организации кода. И получать кучу функций с постфиксами, да, такой вариант я описывал. Ты тоже не проникся фен-шуем этого механизма Эх.. Писал когда-то приблуду для маппинга БД в оперативу на время сессии. Что-то типа ORM, но малость хитрее и со своим блекджеком. И вот, к примеру, возможность выпиливания строк была реализована как перегруженный DeleteRow(); который мог принимать сам объект-строку, мог ее номер для поиска, а мог условие where для выборки внутри корня. Это не просто три разных входа для одной функции. У каждой функции совершенно отличный от других код. Они совершенно разные изнутри, но...дают одинаковый результат, потому и имеют одно имя. Так удобнее. Хотя да, конечно, я мог сделать три функции: DeleteRowByID, DeleteRowByLink,DeleteRowByСondition. Но с одной удобнее и лаконичнее. Ну...не совсем. Я имел ввиду: foo(int $Name0,Object $Name1, String $Name2, int $Name3,Array $Name4), где $Name - однозначное толкование смысла переменной. Хотя, ты это мог подразумевать как само собой разумеющееся, но мало ли. А вообще идея не плохая, и я считаю, что тип данных надо указывать только в случае, если действительно имеет место перегрузка. Оно и интерпретатору поможет не тормозить на этом моменте, сразу показав, что вот - эти функции закинь в отдельный список, а не проверяй у каждой наличие перегрузочных клонов. Если функция не перегружаемая и существует в одном контексте, то типы указывать не надо. В итоге и овцы сыты и волки целы. И текущий пых не станет не совместимым с уже существующими решениями и образом мышления программистов.
вот истина. разные функции, разный код, делают разную работу - но ты почемуто решил обязательно назвать их одинаково. это просто твое личное желание, оно никак логикой не подкреплено. тоесть можно сделать так и можно и иначе. то что ты выбрал путь перегрузки - совершенно не значит что это единственно правильный путь. это просто ОДИН из ВОЗМОЖНЫХ. в Пхп идеология такая, что перегрузка просто ненужна. нет в ней смысла. нет строгой типизации. бОльшая гибкость. можно сделать все в одной функции, а можно разбить на три разных. следовательно больше свободы у программера. ящитаю это огромный плюс. Добавлено спустя 11 минут 59 секунд: когда я пишу на c++,java - я юзаю перегрузку, ибо как в пхп сделать просто не могу. нравится мне это или нет - неважно, у каждого языка свои правила и идеология. фен-шуй - тут ограничен языком на котором пишешь. у каждого языка он свой. смешивать и навязывать фен-шуй одного ЯП - другому - индикатор недостаточной гибкости мышления. я уже выше говорил. хороший программист не переносит привычки из одного ЯП в другой - он понимает и использует сильные стороны каждого из них (как бы это пафосно не звучало). а если действительно хочется перегрузки и типизации в пхп, и ... - то говорить и убеждать нужно не тут и не меня. обращайся к создателям пхп - убеждай их. авось послушают)
Делают разную работу, но одинаковый по ожиданию результат. Выглядит как утка, ведет себя как утка, значит должна называться уткой. И плевать, что там у нее внутри. бОльшая гибкость подразумевает, что есть меньшая гибкость, но это не совсем так. Сделать тысячу функций-сестричек можно в любом языке. А для "все в одной функции", в языках есть неопределенные типы. Даже в плюсах. Если функция принимает неопределенный тип, она принимает что угодно. И вперед, хватай лопату и разгребай сам, что тебе пришло по кучкам. Да, это понятно, что тут просто воздух сотрясается Но дискуссия, не являющаяся срачем, сама по себе интересна.