Forum PHP.pl

@mike: wcale tak nie jest. Niektórzy przyjmują, że komentarzy powinno być tyle, że po usunięciu kodu i zostawieniu samych komentarzy dało się aplikację napisać od nowa. To o czym mówisz to jedynie jedna z konwencji. Moim zdaniem zawsze się wybiera między:
1. mało komentarzy => kod czytelniejszy ale mniej optymalny
2. dużo komentarzy => kod mniej czytelny ale szybszy

Pomijam fakt, że w tym projekcie część komentarzy jest totalnie kretyńska: zobaczcie np. core/database.php

[PHP] pobierz, plaintext 
		//# What and From
		$SQL = 'SELECT ' .mysql_escape_string($What). ' FROM `' .$this->PREFIX.mysql_escape_string($From). '`';
 
		//# Where
		if ( $Where != '' )
		{
			$Where = $this->convertWhere ( &$Where );
			$SQL .= ' WHERE' .$Where;
		}
 
		//# OrderBy and POS
		if ( $OrderBy != '' )
		{
			$OrderBy = $this->convertWhat(&$OrderBy);
			$SQL .= ' ORDER BY ' .$OrderBy;
 
			//# Pos ( ASC, DESC )
			if ( $POS == 'DESC' )
				$SQL .= ' DESC'; # DESCENDING 
			else
				$SQL .= ' ASC'; # ASCENDING ( DEFAULT )
		}
 
		//# Limit
		if ( $LimitFrom != '' AND $LimitTo != '' )
		{
			$SQL .= ' LIMIT ' .intval($LimitFrom). ',' .intval($LimitTo);
		}
[PHP] pobierz, plaintext 

EDIT:
dzięki za link ale ubogi ten phpDoc.

Ten post edytował SHiP 1.09.2010, 19:52:53

No właśnie kod mnie nie zachęcił, ale może Twój fw ma jakieś szczególne funkcje, których nie widać na pierwszy rzut oka.

Mówisz teraz tak, jak prelegenci z Microsoftu na phpConie. Pytam: dlaczego wg Pana Expression Web jest lepszy od konkurencji? A on: wcale nie twierdzę, że jest lepszy..

Sory, ale skoro nie jesteś pewien, jako autor, że Twój fw ma jakieś atuty, to raczej wątpliwe, aby wyszedł on z garażu. Może to brutalne, co powiedziałem, ale konkurencja jest i skoro nie możesz wypunktować jego mocnych stron - lepiej poświęcić czas na poznawanie innych, rozplanowanych.

Sam od kilku lat rozwijam swojego fw i pomimo setek linii kodu, schematów powiązań między poszczególnymi elementami, nadal nie uważam, że nadaje się jeszcze do publicznych tekstów, znam jego słabe strony, ale jest też kilka mocnych, których inne nie mają.

W przypadku Twojego, niestety, kod nie jest mocną stroną i bez dokumentacji nie da się czegoś wygodnie pisać. Zaskocz mnie, pokaż że warto się nim zainteresować.

Marketing też jest istotny; nie sprzedasz nowej wiertarki z potrójnym udarem, jeśli na półce nie będzie się wyróżniała spośród reszty. Pamiętaj, że Twoja marka nie ma jeszcze wyrobionej opinii, więc musisz jakoś ZACHĘCIĆ odbiorców.

Małe info - poszczególne fragmenty mogą być adresowane do różnych rozmówców.

Ad. referencji -> po pierwsze, używanie referencji do "oszczędzania pamięci" i "zwiększenia wydajności" to jedno wielkie nieporozumienie z takiego prostego powodu, że PHP posiada wbudowany mechanizm leniwego kopiowania, tj. właściwa kopia robiona jest dopiero wtedy, gdy dane mają ulec modyfikacji. Gdy dane są pobierane "tylko do odczytu", odczytywana jest dokładnie ta sama wartość, a ponieważ PHP nie musi tworzyć dodatkowych struktur danych na utrzymywanie referencji, takie coś jest nie tylko szybsze, ale paradoksalnie oszczędniejsze pamięciowo. Ponadto nie realizujesz nawet tego, co piszesz, bo w wielu miejscach owszem, argumenty przekazujesz przez referencję, ale później już robisz zwykłe przypisanie.

Ad. systemu szablonów -> widzisz, gdybyś używał standardowego nazewnictwa, nie musiałbyś nic dostosowywać z nową wersją, chyba że pomiędzy wydaniami ze zmienionym pierwszym numerkiem. Korzystam z wielu różnych bibliotek, które właśnie dzięki temu, że zachowują pewne wspólne konwencje, mogą być bez problemu używane razem i aktualizacja sprowadza się w zasadzie do wgrania nowych plików. Natomiast czym jest standardowe nazewnictwo ->
- http://www.zyxist.com/pokaz.php/standaryzacja_php
- http://groups.google.com/group/php-standar...-proposal?pli=1

Ad. klasy tłumaczeń -> a co ma format PO czy "XML" (w cudzysłowiu, bo nie ma czegoś takiego, jak "format XML". XML to meta-język, w którym dopiero można jakiś język opisać) do MessageFormattera, kiedy jedno i drugie zajmuje się zupełnie innymi rzeczami?
- PO - składowanie i zarządzanie tekstami do tłumaczenia
- MessageFormatter - formatowanie konkretnej wiadomości
Jedno drugiego nie wyklucza - możesz mieć teksty w formacie MessageFormattera, który jest dużo dokładniejszy, niż printf() (zwłaszcza w takich rzeczach, jak np. obsługa liczby mnogiej), zapisane w pliku PO. W ogóle poczytaj sobie nieco o tej klasie, a zwłaszcza na jakiej bibliotece bazuje to rozszerzenie (i ilu producentów i aplikacji z niej korzysta), bo Twoje słowa zupełnie nie pokrywają się z rzeczywistością.

Ad. różnych "opcjonalnych dodatków" - moim zdaniem warto zastanowić się czy niektóre z takich dodatków faktycznie są potrzebne. Już kilkakrotnie przekonałem się, że czasem lepiej jest powiedzieć "ma być tak i koniec", ponieważ w przeciwnym wypadku będziesz miał na każdym kroku mnóstwo dylematów "OK, jak ten moduł jest wyłączony, to mogę to zrobić prosto, ale ponieważ gość może go sobie włączyć, wtedy muszę to przewidzieć i dopisać tu jeszcze 154 ify, by obsłużyć wszystkie możliwe kombinacje".

Ad. PHP 5.3 -> zanim webnull skończy ten "framework", jeszcze wody w Wiśle upłynie. Dziwne, że jakoś nikt nie ma oporów przed polecaniem przestrzeni nazw, tak jak inni nie mają oporów przed ich stosowaniem, a tu się czepiacie o jedną głupią klasę. A potem się będzie biadolenie na blogach, że "PHP 5.3 jest już tyle czasu, a wciąż kupa skryptów nie korzysta z jego dobrodziejstw", tak jak to z PHP 4 było. Zresztą, po co mają to wprowadzać na hostingach, skoro programiści nie znają nawet podstawowych informacji o tym, co w tej wersji wprowadzono i mają podejście, że "po co mają się uczyć, skoro hostingowcy tego nie wprowadzają"? To się nazywa samospełniającą się przepowiednią i ja osobiście nie mam zamiaru w niej brać udziału. Jak ktoś chce być zacofańcem, a potem na to samo zacofanie narzekać, to było mi miło, ja się mu kłaniać nie zamierzam.

@mike: zgadzam się i sądzę, że ilość komentarzy należy zmniejszać do minimum. Czasem jednak skomplikowanie algorytmu/wyrazenia regularnego etc. jest tak duże, że trzeba to opisać w kilku słowach . Po prostu są ludzie, którzy twierdzą inaczej.

@zyx: Czepiasz się szczegółów. Chodziło po prostu o trzymanie tłumaczeń w pliku PO lub w pliku xml(i tutaj np xliff). Wybacz ale Twój wcześniejszy post można było odebrać jakby php 5.3 miało wbudowany system tłumaczący. W dalszym ciągu jednak proszę o przykład, ponieważ klasa zastosowana przez Babcia@Stefa nie jest tragiczna, a obsługę MessageFormattera może w każdej chwili dodać(np gdy 5.3 będzie bardziej popularne).

a ja sie poczepiam trochę bazki

[SQL] pobierz, plaintext 
  `id` int(2) NOT NULL AUTO_INCREMENT,
  `name` varchar(30) NOT NULL,
  `passwd` varchar(180) NOT NULL,
  `privigle` int(2) NOT NULL,
  `restrictip` varchar(200) NOT NULL COMMENT 'Here is a place for PHP serialized array with ip numbers',
  `disabled` int(1) NOT NULL COMMENT 'Is admin account enabled?',
  `unblock_time` int(20) NOT NULL COMMENT 'When the account will become avaible? - Unix timestamp format only',
  PRIMARY KEY (`id`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=2 ;
[SQL] pobierz, plaintext 

1) int(1), int(2) - te cyferki w nawiasach niczemu nie sluzą (sluża jedynie dla zerofill ktorego nie uzywasz) a juz na pewno nie określają rozmiaru przechowywanych liczb
2) `disabled` int(1) NOT NULL COMMENT 'Is admin account enabled?', - wartosc 0 lub 1 przechowujesz w typie INT ktory zajmuje 4 bajty. Tu nalezy dac pole TINYINT ktore zajmuje 1 bajt
3) `passwd` varchar(180) NOT NULL,
po insercie widzialem ze haslo to hash. Czemu wiec mowisz ze moze miec 180 znaków?
4) `restrictip` varchar(200) NOT NULL COMMENT 'Here is a place for PHP serialized array with ip numbers',
to powinna byc dodatkowa tabela
5) `unblock_time` int(20) NOT NULL COMMENT 'When the account will become avaible? - Unix timestamp format only',
o typach czasowych slyszal?

Już pomijam fakt, że adres IP można zapisać via ip2long w INT. A o różnicach w wydajności chyba wspominać nie muszę?