Вызывается некий общий метод (s_query), которому единственному дозволено вызывать сакральный метод  query  транспортного класса.

По форме - непонятно накой было вызывать его через call_user_func_array. Зачем нужно вписывать _mysqliFetchAssoc. Лучше вписать слово 'select', а в s_query получить этот самый _mysqliFetchAssoc из массива настроек транспорта (их еще нужно вписать).
Так может получится еще забавней - 

Fortop, по первой твоей цитате я уже ответил   

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

Логику ты и сам видишь, не глупее же паровоза   

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

и так

Согласись, очень удобно

сам в шоке   Я скорее всего к этому и приду, если честно, то я пока не согласился с таким решением. Но пока оставил так лишь с той целью, если вдруг класс будет расширяться, а в select понадобится какое-либо условие...

PS
вот по этому мне и нужна серьёзная критика 

Добавлено @ 09:33
Да, скорее всего так и переделаю... т.е. нафига столько "транспорта"... нужно напрямую делать вызов


Это сообщение отредактировал(а) Gold Dragon - 27.10.2012, 09:35

В первой цитате вопрос был к gta4kv, который настолько одарен, что не знает что сигнал распространяется не мгновенно.
И до фейсбука от меня примерно 20 хопов и 130мс соответственно. А до контакта всего 12 и 30мс.
В первом случае коннект идет к серверу в США, во втором случае в России.

К примеру, у нас европейские сервера имеют +0.2+0.4с задержки при обращении к яху, в сравнении с серверами в Техасе.



Я пользуюсь IDE поэтому phpDoc решает вопрос с числом параметров.
А вот явное указание их для меня  уменьшает вероятность случайной ошибки => я могу сосредоточить внимание на более важных моментах.

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

Ну а кто же не пользуется IDE и phpDoc 
А что касается ошибок, то в данном случае первый параметр всегда запрос, всё остальное - параметры 

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


Это для использования.
А для модификации этого класса?

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

Списком передавать хорошо, но вот только их количество всегда разное


Это сообщение отредактировал(а) Gold Dragon - 29.10.2012, 07:17

Что-то я не догоняю.
Идет  речь про вот такое?


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

ничего не меняя внутри метода и IDE будет доволен.

Дополнять ассоциативный массив новыми фичами для кэширования можно сколько угодно и каким угодно дополнитеным количеством параметров.

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

Но суть в другом.. У меня есть метод для кэширования результатов запросов


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

Вот по этому мне пришлось написать новый метод.. Хотя может оно и лучше...

Т.е. вызов будет с кэшированием такой

а без кэширование такой

может так? Насколько умный алгоритм расшивающий параметры в строке sql?

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

Ну и смысл тогда в func_get_args и прочем? Я про это и говорю.



Массив тут крайне неинтересен поскольку плохоинформативен и начинает содержать неоднородные параметры (одни для подстановки в запрос, другие для кеширования)
Я из-за похожей методики туго перевариваю Yii - он заставляет помнить кучу ненужного материала или постоянно лезть в мануал.

Подошел бы такой вариант, 

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

Смысл? Процедура транспортного уровня - приватная и как она устроена - никого не должно волновать. Так что пусть получает один параметр - массив. Почему бы и нет? Зачем многократно перекладывать из массива в параметры и обратно, как это было в коде ? Обсуждаемая функция (select) - просто обертка над транспортом. Она должна выглядеть удобно для писателя, а внутренняя - удобно для исполнения. 


В принципе - согласен. 

Можно предложить еще один способ "впихнуть невпихуемое".

к инстанцируемому объекту привязывается опция. 

Вообще, считаю что у Котерова была замечательная идея в DBSimple про то, что нужно явно указывать способ приведения параметров к типу прямо в SQL запросе - макроподстановки при пустом параметре и  макры типа ?d, ?#, ?a . Правда использование "массивных" макр не совершенно, иногда приходится выписывать лишние array_keys и array_values   а если `insert in duplicate values update` - то вообще 2 раза их вставлять...
У pdo есть не менее замечательная идея, что можно использовать "именованные" параметры в строке sql. А вот для указания типа параметра прямо в запросе - не догадались, приходится городить отдельный бинд каждого параметра с указанием типа.
Так что если объединить пару идей, то может получится что-то близкое к совершенству.   Останется только со всем этим добром взлететь...

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

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

Это - именованный параметр. "фильтры" видятся в таком наборе 
- key, value - массивные строковые списки с дефолтным escape'ом строковых параметров у keys
- int, float - проверка параметра на целость - дробность, без escape
- noescape - не ескейпить параметры
Макры для условной генерации


Хотя с IF'ом, вероятно, несколько перегружено, есть ли необходимость в еще каких-нибудь контрольных операторах? 

  

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

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


Смысл шаблонизатора - строка sql-twig шаблона, парсится в строку и из нее собирается функция с помощью create_function. Функция САМА эскейпит параметры и всячески над ними издевается.

Способ работы с ней, вероятно, какой-то такой 

Сейчас поддерживаются только ?\d* параметры, без именования.

Писано за пару часов, так что не обессудьте. Но вдруг кого заинтересует...
https://github.com/Ksnk/sql_template