Доку полистал, последний вопрос отпадает. Буду тестировать скорость. Спасибо. Кстати, забавно, но перед тем, как написать вопрос, как раз опробовал worker, подумал, может есть более простой способ решения моей проблемы, о котором я не знал..
И важный вопрос, если Вам довелось использовать cheerio, есть в нем метод index() ? для вычисления позиции элемента в наборе? (чтобы узнать индексы ячеек)
2 способ я так понимаю, замедлит сам обход, так как там циклы. Первый метод, надо попробовать.. Скорость разбора у cheerio достойная? Не будет ли падения производительности по сравнению с jquery ?
Each individual or organization can register up to 100 devices per product family per membership year for development and testing. You can register 100 devices of each type per year. For iOS apps, you can register 100 iPad, 100 iPhone, and 100 iPod Touch devices.
В этом-то и суть, что при таком подходе у меня вылезает ошибка:
Call to a member function prepare() on null in
так как в классе A (из вашего примера) есть метод:
public function query($query){
try {
$this->stmt = $this->dbh->prepare($query);
}
catch(PDOException $e){
//$this->cancelTransaction();
$this->errorSend($e->getMessage());
}
}
svd71: Ну так перед этим можно написать "SELECT id" например.. Из топика предположил, что автору нужно потом работать с данными, которые он извлек.. Ежели ему нужно просто подсчитать количество строк в таблице - ваш вариант кажется рациональнее.
Тимофей: попробую выяснить у знакомого дельфиста.. На самом деле, как не пытаюсь перестроиться на классы в php ну ни как не получается.. То избыточность, то еще что-то..
Собственно по этой причине я обратился сюда. Теорию я читаю и продолжаю читать, но хочется общения с коллегами, которые смогут в тезисной форме указать на ошибку в моей, достаточно тривиальной логике. И остальным, думаю, будет полезно..
Но ведь возможность (следствие) переопределять методы есть в потомке. То есть именно переопределять, а не дополнять.. То, что я не смогу создать объект по причине запрета в конструкторе - абсолютно нормально. Я предполагаю, что любой метод в родителе, я могу переопределить в потомке например на уровне {} что приведет к тому, что метод наследуемый потомком от родителя не будет работать. Или же будет работать так как я напишу в потомке. Именно по такой логике я шел, считая переопределение доступности конструктора - переопределением метода.
Вполне логично на первый взгляд, что если в потомке метод сделали приватным, то "родить" потомка уже не будет возможности (стандартным методом) Однако родителя можно будет "родить" по прежнему.
И ошибка при вызове конструктора у потомка будет вполне логична.
Однако если создавать его как синглтон, то возможность будет.
Хорошо, что наследуемый класс обладает всеми функциями родителя. И пусть он обладает родительской функцией создания новых объектов. Однако я предполагал, что public методы на то и public, чтобы их можно было переписывать в extended классах. В том числе и их доступность, так как это же контекст уже нового класса.. Причем не имеет значения construct это или нет. Я предполагал что можно будет обращаться к construct родителя через явное parent:: ... Видимо логика другая
fancybox.net
А если уж что-то своё:
$.ajax().done(function(){
Тут где-то вставили картинку и приписали что угодно
})