
|
 |
 |
<?PHP Новини ?> 21.11 - 04.12
|
 |
|
|
 |
 |
от Andrey(5-12-2002)
С известно зaбавяне отново ви представям новините покрай PHP.
- Започвам с това, че в ZE2 бе добавена нова ключова дума abstract. Чрез нея могат да се декларират абстрактни методи. Те нямат тяло и при опит за тяхно извикване се генерира грешка.
- В PECL в PEAR (аналог на CPAN) се намират различни експериментални и не чак толкова експериментални модули. Един от тези модули е модул-обвивка за ImageMagick пакета. Някои от вас може би знаят, че imagick има експортнато API за Perl. През изминалия период се появи втори модул и той ще замени досега същестуващия, като не се запазва обратна съвместимост с досега написания код използващ библиотеката. За повече информация относно модула :
тук.
- За занимаващите се с генериране на графични изображения с помощта на PHP може да е от интерес следният модул: http://mmcc.cx/php_imlib/. За съжаление, от известно време насам модулът не се разработва.
- От месеци форумът за разработчиците на PHP не е "виждал" такава разгорещена дискусия като тази за локализацията на съобщенията на PHP. Дискусията започна от друг проблем: за някои разработчици показването на E_PARSE грешки е незадоволително и те пожелаха да има възможност да се прехвърля потребителя на друга страница или Apache да връща грешка 500 когато се генерира Е_PARSE. Това предложение бе отхвърлено с мотива, че то би създало объркване за повечето от разработчиците, още повече, че е възможна проверката на скриптове за Е_PARSE без дори да бъдат качени за изпълнение. Това може да се извърши по следния начин:
php -l file_name.php
Ако имате синтактична грешка в скрипта ще получите информация къде е.
Но да се върна на дискусията за локализираните съобщения. Повечето основни PHP разработчици се обявиха срещу това. Бяха дадени идеи съобщенията да бъдат прехвърлени в XML или CDB файлове за по-лесна поддръжка. Основните аргументи против тази промяна са:
- Увеличена поддръжка при неувеличени човекоресурси.
- По-малка вероятност за помощ за програмисти, които търсят помощ и дават съобщения на език различен от английски. По тази причина ако разработчикът си няма представа какво е "Синтактична грешка", много по-малък кръг хора могат да му помогнат.
Покрай локализацията на съобщенията бе изявено желанието и всяко съобщение да има свой собствен уникален идентификатор, който да дава възможност за по-бърза и качествена помощ - като например бърза справка в help-a или чрез Google. В крайна сметка бе решено съобщенията да останат на английски, а с известна доза вероятност да бъдат създадени уникални идентификатори на съобщенията.
- В скоро време в PECL ще се появи модул-обвивка за libradius, a модул за работа със Samba можете да откриете тук. През периода Hartmut Holzgraefe каза, че има готов модул обвиващ libuuid. Тази библиотека върви с ext2fs tools.
- Бяха направени няколко поправки в xmlrpc модула. Може би вече е възможна неговата компилация под Windows.
- Докато в ZE1 e възможно да декларирате функции във функции (но трябва да декларирате само веднъж - прилага се защита, чрез define()) и да include()-вате код в локалното пространство на функцията, в ZE2 това няма да е възможно. Едно от възможните приложения на горепоказания метод е за симулиране на plugin-и. Все пак програмистите не трябва да се чувстват разочаровани, защото динамичното зареждане в ZE2 ще става чрез агрегация. За тези, които не знаят какво е агрегация, препоръчвам да прегледат книгата на Круглински за "Visual C++ 6.0".
- Още през далечната 1997-ма е бил повдигнат въпроса с преобразуването на числа не в десетична бройна система, които се намират в низове:
php
print (int) "0xA" + 0; // prints 0
print (int) ("0xA" + 0); // prints 10
?>
В първия случай "0хА", което е шестнадесетично 10, се преобразува до 0 вместо до 10. Във втория случай се преобразува до 10 и се добавя към 0 за да се получи 10. Възможно е в близко бъдеще да бъде намерено решение на този "проблем".
- С ключовата дума public вече е възможно да се декларират и член-променливи на класове (ZE2) - еквивалент на var от ZE1, като се запазва обратната съместимост. За момента това е реализирано чрез псевдоним, поради което е възможно, но не и правилно, да декларирате метод по следният начин:
var function a() {}
Все пак това няма да бъде възможно в крайната версия на ZE2. Искам също да добавя, че от известно време насам има поддръжка на private и protected променливи. За методите нещата не са 100% ясни все още.
- Излезна RC2 на 4.3.0. Надявам се в най-скоро време да излезе крайната версия. Писна ми да чакам :)) За тези, които искат да пробват RC2: http://qa.php.net.
- В предишните колонки обявих нова версия на APD. Излезе и новата стабилна версия след 0.2 - това е версия 0.4p1. Вижте тук.
- За завършек искам да представя една нова функция, която се появява във 4.3.0. Това е debug_backtrace(). Първоначално това беше възможност само на ZE1, но след разгорещени дискусии бе добавена и в ZE1 oт Thies Arntzen (един от разработиците на модулите за Oracle). Тази функция ви връща многомерен масив със стека на извикванията. Ако още не ви е ясно - ако сте ползвали Java сигурно сте виждали какво се получава при изключения - изписва се стека с извикванията. По този начин може да дебъгвате по-лесно различни приложения. Един пример: ако сте отделили кода за работа с база данни в клас то е много лесно в случай на неправилна заявка да се покаже къде точно е генерирана тя (къде е извикан метода за изпълнение на заявка) и точно какви параметри са подадени. Досега имаше 2 възможности - при работа с Mysql да правите следното:
($_err = mysql_error())
&& log_error_printf(
"Ooops : [%s][%d][%s][%s]\n",
__FILE__, __LINE__ - 1 , $sql, $_err);
или
$this->db->query($sql, __FILE__, __LINE__);
Първото определено загрозява кода и го увеличава. Второто е удобно, но все пак изисква повече писане и да се пише всеки път на заявка.
Тъй като дори var_dump() на масива върнат от debug_backtrace() не е много четим, наскоро бе добавена функцията debug_print_backtrace(), с която вече е по-лесно да се прегледа информацията.
P.S.
Автора благодари на г-н Пейо Попов за предложението за ново име на колонката.
<< SCMxx - Linux софтуер за Siemens телефони | Проблеми с ext3 и ядро 2.4.20 >>
|
 |
 |
 |
 |
Kakwo stana s PHP sita? От: Ivan Kalvachev На: 4-12-2002@22:50 GMT+2 Оценка: 1/НеутраленBassi, 4owek ne moje da wi kritikywa, kazwa wi 4e pi6ete prekaleno 4etso, i wie go zasipwate s tonowe pisiqa....
btw Towa novina li e ili statiq?
btw bgit.net ima golqma nyjda ot novini 6to ne po4nete i dam da poblikywate buletina si...
[Отговори на този коментар] Re: Kakwo stana s PHP sita? От: phps На: 5-12-2002@7:37 GMT+2 Оценка: 1/Неутраленpich, ne se obajdai molia te. kato si nekompetenten v niakoia oblast i ne ti e interesna ne prechi pone na ostanalite. tova e linux-bg. bgit ako ima nedostig ot novini/postove znachi ili ne mogat da si poddyrjat saita ili niamat vreme ili ne e tolkova atraktiven visualno i kato ideia. aide vanka, ti idi postvai tam. begom, iskam da kaja.
[Отговори на този коментар] Chestota От: Andrey На: 5-12-2002@11:50 GMT+2 Оценка: 1/Неутрален Purvonachalnata mi ideia beshe da pisha vednug sedmichno. Za sugalenie, napisvaneto na kolonkata otnema ne po-malko ot 1 chas. Tazi mi otne po-malko zashtoto pochnah da si vodia zapiski v linux-bg(neshto kato ToDo). Vie sushto mogete da polzvate tazi vuzmognost tochka "Zadachi" ot meniuto v liavo.
V krajna smetka izliza che pisha na okolo 10 dni, koeto spored men e negoliam interval. Viarno che svodkata ne e kusa, no mislia che kolkoto poveche neshta pisha, tolkova interesite na po-goliam krug ot hora shte zasegna. Razgovarial sum sus Slaff i Mircho otnosno vuzmognostta da se otdeli i chast za takiva tekushti novini, no neshtata sa samo na faza razgovor.
Otnosno bgit.net . Nishto ne prechi na horata tam da ni linkvat. Ako se otdeli chast ot linux-bg kakto e ideiata otgore, dori rss news feed moge da se izkara i taka neshtata shte stanat oshte po-avtomatizirani.
Za sugalenie lipsvat hora, koito da pishat po strogo specializirana tema. Az sum zapoznat s "kuhniata" na PHP i zatova pisha za neia. Po sushtia nachin g-n A. Keremidarski moge da se vkliuchi s dvusedmichni novinki ako jelae. Dokolkoto razbrah ima chovek, kojto e navutre s Apache Group. Dostatuchen e samo po edin chovek. Ne e nugno da se natovarva mnogo. Moge da pishe po 30-40 izrechenia i shte imame neshto hubavo.
Imam jelanieto i da pisha statii. Tova moge da se suchetae s tiahnoto izlizane na bulgarski i anglijski (v sluchaj che ot PHP-mag.net pojelaiat da izdadat statiite). Za sugalenie vremeto za napisvane na statia ot niakolko stranici ne e 1-2 chasa i tova oznachava po-goliama angagiranost plius che statiite niama da mogat da izlizat na takuv interval kato novinite, no vse pak e neshto.
Primerni statii :
1)kak da profilirame i optimizirame Apd
2)Kak da dokumentirame s PHPDoc
3)Tehniki za optimizacia.
4)Tehniki za povishavane sigurnost
Ako niakoj ima komentari shte sum blagodaren da gi procheta.
[Отговори на този коментар] :) От: Ivan Kalvachev На: 6-12-2002@1:45 GMT+2 Оценка: 1/НеутраленНека и аз ти дам предложение за името на "новината" -
Мисля че "PHP бюлетин", би описал много по-точно това което правиш, защото като гледам има доста "клюки" от "кухнята".
Мое лично мнение че колкото повече неща слагаш толкова е по-малко хора ще го четат, просто безинтересните теми се увеличават. Нека това не те спира....
Наистина би било хубаво да има отделна секция за бюлетини/сводки, където всяка записка от твоето "TODO" да се появява веднага. Виждам го примерно така:
Заглавие на секцията (Бюлетин / Сводка от OSS фронта...)- , под него по един ред за всеки вид бюлетин - PHP,Java, Apache ...., за всеки вид бюлетин едно номерче което показва преди колко дена е последната бележка/новина/сводка.
Така news секцията няма да се спамва, а всеки може да си чете бюлетина по интерес....
P.S.
phps - един много популярен чикагски ганстер е казал: "С добра дума и пистолет може да постигнеш много повече, отколкото само с добра дума". Така че когато вадиш пистолет не забравяй добрата дума :)
[Отговори на този коментар] Абсурдно От: Никола Антонов <linux (a) logos __точка__ goto __точка__ bg> На: 6-12-2002@7:13 GMT+2 Оценка: 1/НеутраленAndrey, ако всеки от нас полагаше
толкова старание и така
професионално списваше
новинарската рубрика, както го правиш
ти, сигурно на останалите нямаше да
им прави впечатление. На фона на
новините от по 3-4 изречения с линк
към някой англоезичен сайт твоите
неща просто изпъкват и вместо да се
опитаме да бъдем информативни като
Andrey ние искаме да стане точно
обратното:)) Много абсурдно, но е
факт. Аз подкрепям напълно
инициативата ти, а за отделната
рубрика това вече зависи от
уебмастерите и тяхното свободно
време.
[Отговори на този коментар] phpdev От: phps На: 6-12-2002@20:09 GMT+2 Оценка: 1/Неутраленm/u vsichki prikazki okolo razvitieto na php nikoi ne se opita da tyrsi loshite strani.
kakto az go vijdam loshoto e che m/u 3.x/4.0.0 i 4.4/current se sluchiha ujasno mnogo promeni, chiito broi beshe tolkova goliam, che pochva da se chustva niakakva nesigurnost u programistite - mnogo funkcii biaha mahnati i ne se poddyrjat, drugi dobaveni, treti promeniani; niakoi standarti se promeniha. syntaxisyt kato cialo ne se promenia mnogo, no se promenia!
za kapak na vsichko ima mnogo golemi protivorechia i se ochakvat oshte poveche promeni. deleoperite ISKAT niakakyv konstanten standart na programirane, a ne n promeni prez m sedmici ;(
[Отговори на този коментар] promeni От: Andrey На: 9-12-2002@8:52 GMT+2 Оценка: 1/НеутраленGolemite problemi za niakoi mogat da dojdat s php5. Reshenieto v tozi sluchaj e da ne migrirat kum nego. Dokato migraciata mgedu 3 i 4-ta versia e bila lesna i e bila nugna, to preminavaneto kum versia 5 niama da e zadulgitelno. Promeni ima i vinagi shte ima. Pitaj gi programistite na VB kak im e s novata koncepcia za ezika v .NET. Hora deto si niamat predstava ot OOP sa im predostaveni sredstva da go praviat.
Ne sum 100% siguren, no funkcia na PHP niama mahnata pone vuv versia 4. Edna funkcia moge da bude "deprecated", no tova ne prechi da se polzva. Razbira se dobre e da se prenapishe koda, kojto ia izpolzva. Opredeleno moga da kaza che za da se stigne do "deprecated" regim na dadena funkcia ima naistina dobri dovodi. Edin primer e funkciata mysql_db_query(). Nezavisimo ot imeto si, tia smenia tekushtata baza i ako predi izvikvaneto i ste bili zakacheni kum edna baza (govorim za 1 host), to sled neia shte budete kum druga i ako sled tova napravite mysql_query() naj-veroiatno zaiavkata shte vi izgurmi sus suobshtenieto che ne namira edi koia si tablica v bazata spomenata v mysql_db_query().
MOga da vi uveria che celta e vinagi 100% obratna suvmestimost, zashtoto PHP ne iska da razocharova svoite razrabotchici. Kum niakoia funkcia moge da bude dobaven dopulnitelen parameter, no tova ne oznachava che stariat kod niama da raboti kakto predi.
Funkcii vinagi sa bili dobaviani, taka se obogatiava sredata (ne iskam da kaga ezika), zashtoto php ne e pascal.
Nadprevarata e biasna, i ako PHP reshi da zamrazi svoeto API, to togava, toj shte zagubi mnogo. ASP i JSP sa po petite mu, da ne govorim kakva konkurencia e .net na MS, i osobeno fakta che ima 2 proekta(pone az znam za tolkova) koito se opitvat da podkarat .net v Linux sreda. Po otnoshenie na Mono i Portable.net smiatam che dopulnitelno nalivat voda v melnicata na MS.
I otnovo za promenite. Ne smiatam che sum mnogo navutre s Python, naprotiv. No dokolkoto sum chel negovite razrabotchici sushto promeniat neshtata s biasna skorost. I python maj idva kato 2 rpm-a za RH suvmestimi distribucii. Python1 i Python2. Python opredeleno ne e supernik na PHP na web scenata, no prosto go davam za primer.
Moge bi naj-golemiat mi strah e che programistiter poniakoga se otegchavat i si ostaviat rabotata na polovina. Kogato ne rabotish za pari i v sluchaia za OS proekt si pravish kakvoto ti haresva, kogato si poiskash i kolkoto si poiskash. V sluchaia na PHP Pri se suzdavat dosta goliamo kolichestvo moduli, no opredeleno malka chast ot tiah uspiavat da se zadurgat na povurhnostta - da se raboti po tiah neprekusnato. Viarno che ima dosta moduli koito sa stable i na tiah ne bi i triabvalo da se obrushta mnogo vnimanie, no za sugalenie ima mnogo nedonoscheta, na koito ne se obrushta mnogo vnimanie.
[Отговори на този коментар]
|
 |
|
|
|
|
|
|