it-swarm-eu.dev

Jaké funkce byste chtěli mít v PHP?

Vzhledem k tomu, že je to sváteční období a všichni si přejí, zajímalo by mě - jaké jazykové funkce byste si přáli PHP? Zajímají mě nějaké praktické návrhy/přání pro tento jazyk. Prakticky mám na mysli:

  1. Něco, co lze prakticky udělat (ne: „Přál bych si PHP by hádal, co můj kód znamená a opravil chyby pro mě“ nebo „přeji, aby se jakýkoli kód spustil do 5ms“)
  2. Něco, co nevyžaduje změnu PHP do jiného jazyka (ne: „Přál bych si, aby upustili znaky $ a místo mezer použili místo mezer“ nebo „Přál bych si PHP) byl kompilován, staticky napsán a měl # in is name ")
  3. Něco, co by nevyžadovalo porušení veškerého existujícího kódu (ne: „Přejmenujme 500 funkcí a změníme pořadí parametrů“)
  4. Něco, co mění mění jazyk nebo jeho zajímavý aspekt (ne: "Přál bych si, aby existovalo rozšíření pro podporu protokolu XYZ" nebo "Přál bych si, aby chyba # 12345 byla konečně opravena")
  5. Něco, co je víc než chvástání (ne: „Přál bych si PHP, aby to tak špatně nezasálo“)

Někdo má nějaké dobré přání?

Mod edit: Stanislav Malyshev je hlavní vývojář PHP.

88
StasM

Nevadilo by mi jmenovat parametry.

getData(0, 10, filter => NULL, cache => true, removeDups => true);
// instead of:
getData(0, 10, NULL, true, true);

// or how about:
img(src => 'blah.jpg', alt => 'an albino platypus', title => 'Yowza!');

Bohužel PHP devs sestřelil tuto myšlenku dolů již.

Více dereferencí:

echo something_that_returns_array()[4];

Jiní uvedli pojmenované parametry a kratší syntaxi pole. Vadilo by mi také kratší syntaxi objektu.

$a1 = array(1, 2, 3, 4);
$a2 = [1, 2, 3, 4];

$b1 = (object)array('name' => 'foo');
$b2 = {'name' => 'foo'}; // or something?
93
Annika Backstrom

Po práci s PHP asi 13 let a těžce s JS asi 4 roky si myslím, že pár věcí si myslím PHP by si půjčil od JS dobře) :

1) zkratkový zápis pro pole a objekty. Věřím, že to mohlo být diskutováno a sestřeleno na Internals (takže slyším - nerad vidím, jak se klobása vyrábí), ale opravdu, opravdu zjistím, že doslovný zápis polí a objektů v JS je velký produktivita vítězství.

Například:

$arr     = [1,2,3,4];
$assoc   = [foo=>'bar', baz=>'boo'];
$stdobj  = {foo->'bar', baz->'boo'};

Je (IMHO) mnohem jednodušší psát a čistit než

$arr     = array(1,2,3,4); // not too bad
$assoc   = array("foo"=>'bar', baz=>'boo'); // not too bad either
$stdobj  = new stdClass; // this gets pretty rough
$stdobj->foo = 'bar';
$stdobj->baz = 'boo';

Slyšel jsem, že byly vzneseny určité obavy ohledně možného zmatku, ale je to skutečně více matoucí než, řekněme, heredoc notace? Přinejmenším je to, že vytvoření objektu stdClass v PHP) je dost podrobná, aby odradila od praxe.

2) Schopnost předefinovat dříve definované funkce a metody by bylo opravdu užitečné. Zjednodušilo by to zejména situace rozšíření třídy a vytvoření nové třídy je buď příliš složité nebo nepraktické. Domnívám se však, že bychom se měli vyvarovat předefinování základních funkcí a metod neuživatelského prostoru.


Kromě těchto dvou, myslím, že PHP musí transparentně podporovat unicode. To se pro vývojáře stává stále větším problémem a řešení, která jsou v současné době nabízena v PHP, jsou matoucí a často neúčinná). Vyřazení všech standardních funkcí řetězce Unicode z krabice by bylo masivní výhra pro programátory PHP).

Díky za optání!

72
Funkatron

Věci, které bych jako bývalý dlouhodobý omluvitel PHP rád:

  1. Kratší syntaxe pro pole. PHP pole jsou jednou z nejúžasnějších vlastností jazyka kvůli jejich flexibilitě, ale je to drag to write some_array_method($argity, array('key' => $value));. Věřím, že tento návrh již byl bohužel uveřejněn v poštovním seznamu PHP.
  2. finally podpora
  3. Atributy/anotace. To vám umožní přidat vlastní chování k metodě způsobem, který umožňuje opakované použití kódu. Například v rámci MVC lze definovat AuthorizeAttribute, který by naznačoval, že řadič nebo metoda akce vyžaduje, aby byl uživatel autorizován. Rámec sám by byl zodpovědný za hledání atributů a podle toho na ně jednal. Věřím, že PHPUnit již používá nějaký atribut tím, že je vkládá do komentářů docblocku, které lze číst pomocí reflexe, ale uvedení skutečné funkčnosti do komentářů docblocku je určitě hack.
  4. Kratší lambda syntax. Místo toho, abych musel psát function($x){ return $x*2;}, možná bych mohl napsat $x => return $x*2, Nebo tak něco. To je opět něco, kvůli čemu je tato funkce nutná. Například $results = array_filter(array(1,2,3), function($a) { return $a % 2; }): vs $results = array_filter(array(1,2,3), $a => return $a % 2 ); Bývalý má jen mnohem víc instalatérství, které je v podstatě irelevantní pro skutečnou práci, kterou se snažíte provést.
  5. Vestavěné Decimal (matematika s pevným bodem), které podporovalo matematické operace prostřednictvím normálních operátorů, by bylo docela pěkné, protože nemáme přetížení operátorů.
  6. METODY MOAR MAGIC. Magické metody jsou skvělé. Viděl jsem PHP přidávající přetížení operátorů pomocí magických metod (vím, že se to v podstatě nikdy nestane.) Obecně však poskytují opravdu skvělé způsoby, jak se zapojit do jazyka a dělat skvělé věci.
48
davidtbernal

Make PHP opravdu objektově orientovaný.) slap on another global function Evoluce PHP musí skončit).

array_merge(array_filter(array_intersect_key($arr1, $arr2), "is_int"), $arr3);

To je pro mě těžké číst. Musím si vytvořit svůj vlastní mentální zásobník a sám to zkompilovat. V zásadě by to mělo být na zadní straně. $dog->wakeup()->bark(); je snadno čitelné ve srovnání s bark(wakeup($dog))

$arr1->array_intersect_key($arr2)->array_filter("is_int")->array_merge($arr3);

Nyní jste udělali krok k povolení podpory objektů a metod, nyní je prosím použijte ve skutečných jádrech PHP funkcí).

Přejmenujme 500 funkcí a změníme pořadí parametrů.

Posun této funkce na metody by jim umožnil jejich přejmenování pomocí některých důsledně. Přerušilo by to zpětnou kompatibilitu, pokud by řetězce a pole měly své vlastní metody?

48
Keyo

Jazykově integrovaný dotazovací stroj by byl skvělý. Něco jako to, co je k dispozici v .NET s názvem LINQ. Pomohlo by to třídit pomocí rozsáhlých polí dat a standardizovat přístup k databázi, aby bylo úspěšných méně útoků SQL-injection.

40
Nick Berardi

Ach. Typové rady pro primitivy. To by bylo hezké.

38
ruurd

Opravdu si přeji lepší podporu Unicode hned po vybalení. Většina jazyků se pohybuje tímto směrem, ale PHP stále mají podivné příkazy poseté všude).

Řetězce PHP jsou pouhá bajtová pole. Jejich obsah je nepřenosný, protože závisí na aktuálním výchozím kódování.

Totéž platí pro reprezentaci vytvořenou serializací. Obsahuje bajtovou reprezentaci řetězce s předponou délky bez skutečného uložení jakékoli kódovací informace.

Většina funkcí PHP (string) nemá ponětí o Unicode. Podrobný seznam včetně úrovně rizika každé funkce naleznete na: http://www.phpwact.org/php/ i18n/utf-8

http://blog.ginkel.com/2010/03/php-unicode-support-or-the-lack-thereof/

34
Emil Stenström

Vytvořte řetězce jako například pomocí vestavěných metod, které nahradí nekonzistentně pojmenované a parametrizované nepředmětné. např.

$subject->replace($search,$replace);
$string->split($separator);
$string->trim();

atd.

Edit: ještě jedna věc: Tyto metody by měly vždy očekávat a emitovat UTF-8, s výjimkou těch, které jsou konkrétně určeny pro kódování. Pokud je vstup neplatný UTF-8, měla by být vyvolána výjimka, i když by výstup funkce nebyl kódováním ovlivněn.

32
rjmunro

1) Rád bych, aby nově vytvořené objekty vrátily „$ this“, abych mohl použít řetězec $ user = new User ('john') -> setLastName ('Doe') -> save ();

2) Pokud jste někdy použili Ruby a naposledy uzel, mají skvělý interaktivní Shell (IRB). Rád bych PHP) měl ten, který byl skutečně užitečný.

3) Znaky/Mixiny, ale slyším, že jsou na cestě.

4) Chci sekundovat krátké pole $ myArray = ['my', 'array'];

5) Jednotné pojmenování/pořadí (tj. Stoh sena)

24
Jakefolio

1) zbavte se zahrnutí (). Odkazy na jiné soubory by měly být odkazy a neměly by obsah jednoho zdrojového kódu ve skutečnosti umisťovat do jiného. Příliš mnoho PHP programátoři, kteří používají programátor, zahrnuje () jako typ volání funkce než prostředek odkazování na knihovnu. To vede k nejrůznějším nejasnostem v proměnném stavu a nestabilním kódu. Nahraďte jej příkaz „použití“ typu Perl.

2) Uveďte out of the box metoda kompilace PHP aplikace do jediného distribuovatelného souboru s bajtovým kódem nebo spustitelného souboru, což výrazně zvýší přitažlivost PHP jako jazyk komerčního vývoje. Mělo by to být základní součástí jazyka. Nedělejte si starosti soubory html používané pro GUI aplikace, protože ...

3) Zbavte se prosím možnosti vkládání tagů PHP tagy do HTML.) Nebo přinejmenším poskytněte režim „bez vložení“. To je absolutní nepořádek a podporuje špatný design smícháním aplikační logiky a prezentace Vývojáři by měli používat šablony pro zobrazení a ne fackovat PHP dohromady) a doufat v to nejlepší.

Podepsaný,

GrandmasterB

ps: neposlouchejte, co ostatní říkají, byl jsem pěkný celý rok

20
GrandmasterB

Ini směrnice pro E_ERROR na nedefinovaných konstantách, spíše než předpokládat, že se jedná o řetězec s E_NOTICE.

18
Annika Backstrom

Normalizujte globální jmenný prostor pomocí dobře promyšlené konvence pojmenování, která dává smysl novým uživatelům!

Citovat našeho milovaného Jeffa Atwooda: PHP naštve, ale na tom nezáleží !

14
David Murdoch

1) Kratší syntaxe pole/objektu, a la JavaScript (jak bylo uvedeno výše)

2) Povolte proměnné const, aby umožnily výsledek výpočtu jako define().

3) Řetězení přímo od konstruktéra: new User()->name('Ryan');

4) Odpojení pole: something_that_returns_array()[4];

5) Rozšířená podpora SPL. SPL provádí slušnou práci při reimaginaci řetězcových a maticových funkcí (mimo jiné) jako objektů. Rozšiřující se SPL by mohl vyřešit spoustu gripů o tom, jak je jazyk tak skličující.

6) Použití ArrayObject() by mělo být stejně průhledné jako použití array(). Měli byste být schopni dělat věci jako array_filter($array_object_instance), aniž byste dělali array_filter($array_object_instance->getArrayCopy()). Ještě lepší by samozřejmě bylo $array_object_instance->filter().

7) Plné Unicode by bylo pěkné.

8) Přestaňte dělat divné automatické převody typu. Neměli byste například být schopni echo objekt SimpleXMLElement, aniž byste jej nejprve explicitně zadali jako řetězec. Nebo alespoň něco hodte, když se to stane (např. V přísném režimu nebo v jakémkoli režimu error_reporting(-1)).

9) Podpora pro více vláken nebo pro jakýkoli druh eventuálních/asynchronních zpětných volání. To je nejdůležitější, když se pokoušíte nahrát velké soubory přes cURL. Namísto starých vláken ve skocích by bylo něco jako Apple Grand Central Dispatch Nice. Nebo dokonce něco podobného JavaScriptu, kde můžete provádět asynchronní požadavky a definovat zpětná volání.

10) Konzistentní pojmenování/pořadí (tj. Stoh sena) by bylo pěkné, ale myslím, že by to mohlo být lépe vyřešeno pomocí SPL.

11) Oficiálně podporovaná interaktivní PHP Shell, jako IRB. Facebook má jednu s názvem phpsh, která byla napsána v Pythonu, ale postrádá polštář, který bych rád viděl).

12) Pro Reflection API přidejte podporu pro (a) docblock komentáře ke konstantám (globální a třída) a (b) podporu pro analýzu komentářů podobných PHPDoc do rozumné datové struktury. Snaží se o to balíček PECL s názvem „docblock“, ale nezdá se, že by se autor dostal příliš daleko.

ÚPRAVA: 13) Také bych rád viděl schopnost používat ! a ? v názvech funkcí - jako Ruby can.

13
Ryan Parman
13
Kemo

Chtěl bych vidět legitimní metodu vytváření/definování konstantních polí. Existuje několik hackerských způsobů, jak simulovat tento druh funkčnosti, ale bylo by hezké, kdyby to byla jen funkce přímého přístupu do PHP. Bylo by hezké, kdybyste mohli vytvořit pole způsobem podobným „závěrečné“ deklaraci Java.

Vytvořil jsem přihlašovací systém, který lze velmi rychle nastavit. Jediné, co musíte udělat, je změnit obsah pole v textovém souboru a určit pole, která chcete pro informace o uživateli. Pomocí řádku pro smyčky zpracovává vše od generování formulářů a senzibilizace vstupů až po volání do databáze, ale vše je závislé na tomto původním poli.

Soubor s maticí je uzamčen s oprávněními, ale jakmile se pole pohybuje v éteru, je zaměnitelné. I když mám pocit, že systém je docela bezpečný, nerad nechávám nic náhodě. Metoda dokončování matic by byla v takové situaci pěkná.

Nová myšlenka !!

Ohhh, myslel jsem na něco jiného, ​​co bych opravdu rád v php. Chtěl bych, aby nějaký systém ovládal operace s php soubory a adresářové operace podobné tomu, jak funguje .htaccess.

Soubor .phpaccess by měl spustit nějakou stejnou zásadu stejné domény/stejného původu.

Například, kdybych hostoval mnoho webů s virtuálními hostiteli, mohl bych mít v adresáři soubor .phpaccess, který by řekl php, aby zkontroloval orginál všech prováděných skriptů, které se snaží pracovat v mém chráněném adresáři. Pokud skript nepochází z tohoto adresáře nebo jeho podadresářů, operace se soubory nebo sokety budou odmítnuty.

Myslím, že takový systém by z virtuálního hostování učinil mnohem bezpečnější prostředí. Pokud byste jeden z nich umístili na začátek každého virtuálního hostitele, snížilo by to šanci, že někdo najde způsob, jak se vplížit od sousedního virtuálního hostitele.

Také, pokud by bylo dobré mít způsob zajištění tímto způsobem inverzně. tj. omezení dosahu skriptů v jednom adresáři na tento adresář.

Je to jin a jang, kteří to vědí!

12
Dave B.

1) Porozumění pole ve stylu porozumění seznamu Python seznam porozumění:

$newlist = array($x->something for $x in $oldlist);

//with short array syntax:
$newlist = [$x->something for $x in $oldlist];

2) Syntaxe krátkého pole

$newlist = [1,2,3,4,...];

3) Make empty () nepovažujte řetězec '0' za true

12
sfrench

Moje dvě největší přání jako hardcore PHP programátor:

  1. Podpora konečně. Je to velký nepořádek, aby se to smyšleně obešlo vlajkami nebo podobnými prostředky.
  2. Rád bych viděl podporu syntaxe C # pro getery a settery. Pokud máte spoustu getterů a setterů, jednoduchá syntaxe, jako je C #, je skvělým posilovačem výkonu, místo toho, abyste to dělali metodou Java a psaním getterových a setterových metod.) Magické metody jsou úžasné v případech, kdy chcete vytvářet členy dynamicky (například pokud chcete poskytnout vykreslovacímu modulu některé proměnné, které chcete použít), ale nejsou dobré pro normální vlastnosti, u kterých byste chtěli automatické doplňování IDE), víte jejich typy atd. Pomohlo by to zmenšit kód tak, aby byl stále čitelný a snadno použitelný.
11
Johnco

Syntaxe jazyka : Existuje několik dobrých stop v pihipi a phpreboot , o co se vývojáři zajímají (ačkoli phpreboot jde příliš daleko do JS).

Metodika vývoje : Výrazně by se prodloužila životnost PHP.net, kdyby takové průzkumy byly skutečně zohledněny. Nedělejte žádné další chutné odpoledne IRC syntaktická rozhodnutí relace).

Jednotlivé rysy : Některé již byly zmíněny dříve, ale naštěstí spálím nějakou karmu, aby zde byla navíc tupá:

  • Typ řetězce Unicode.
  • Bigint (viz Python).
  • Runkit builtin k odstranění/přejmenování/přepsání vestavěných funkcí a tříd, které nejsou vždy tak dobře navržené.
  • Moderní OOP
    • vícenásobná dědičnost (namísto složitosti pro podporu zřídka případů Edge se syntaxí neohrabaných znaků)
    • skaláry se mohou zdvojnásobit jako objekty (viz Python), např. array () funguje jako ArrayObject nebo řetězce jako SplString (vyžaduje použitelné metody, všechny řetězce funkcí by měly být k dispozici jako str::toupper())
  • Zastarat hovno sračky \ Syntaxe jmenného prostoru , opravit parser a jako alternativu použít ::. Víte, jako skutečný jazyk.
  • Jakákoli varianta LINQ (přestože vám nevěřím, že vy vymyslíte rozumnou syntaxi)
  • nebo literály XML.
  • Zbavte se běhového chování php.ini a sémantických přepínačů. Vylučuje některé vzrušení, pravda, ale prospělo by to vývojářům a uživatelské základně.
  • Ano, magic_quotes ještě nejsou pryč.
  • Převeďte bajtový kód Zend Engine na PBC

I když, pokud to není zřejmé, ráda bych finančně podpořila kohokoli jiného, ​​kdo by to udělal, a zabil jsem php.net jako hlavní implementaci. :P
Oh, jen jsem si všiml, je to komunitní wiki. Takže existuje šance, že tu pro karmu nejste, ale skutečný zájem. Pokud ano, podívejte se na <b> vydání </b>, které vážně bolí jazyk (ředitelka).

9
mario

Rád bych viděl sjednocení chyb a výjimek do jediného konceptu (výjimky). Je skvělé, že je možné zachytit výjimky a zapsat je do protokolu, aby tak našli a opravili chyby. Ale pokud je něco v zásadě špatně (přečteno: PHP Chyba) v codepathu, který je velmi zřídka zasažen, neexistuje dobrý způsob, jak tyto informace přenést do stejné databáze problémů.

Prosím, Santa, představte v php.ini přepínač, který by všechny chyby udělal až na výjimky - ideálně na výjimky, které zachytím v kódu.

8
Alex
  • podpora výčtu (jako Java 1.5+)
  • Umět definovat typy návratových metod v rozhraních a třídách
  • podpora definice anotací/metadat o vlastnostech a metodách.
  • být schopen provádět přísný typ hinting pro metody skalární argumenty.
7
Kees van Dieren

PHP mi vyhovuje, protože je to pro klepání malých a středních webových stránek; Musím být trochu nepřiměřená, jediná věc, na kterou bych si mohl myslet, jako odpověď na tuto otázku, je něco, co zlepší měřítko pro stránky s vysokým provozem.

Přemýšlím o vytváření procesů do jiných jader, například o aktualizaci databáze v jednom procesu při vytváření výstupní stránky v jiném procesu. Rychlé vyhledávání google naznačuje, že to lze simulovat, ale v současné době není podporováno přímo v php.

7
geekbrit

Opravdu jsem zmeškal, že skalární typy nejsou považovány za objekty, a skutečné objekty nemohou fungovat jako jakýkoli jiný typ nebo objekt (s výjimkou řetězce kvůli __toString ()).

7
pestaa

Vyčistěte „Poznámky přidané uživatelem“ na http://php.net . Někdy jsou skutečným nepořádkem, ale obecně mají velkou hodnotu.

6
bobah

V PHP existují některé docela slušné funkce pole, které poskytují kapacitu pro zpracování seznamu, s zpětnými voláními a create_function() poskytující základní lambda kalkul.

Hlavním problémem je, že v PHP je příliš podrobný, zkratkový systém by byl vynikající, zejména pokud jde o příkazy map/redukovat.

Ještě důležitější je, že funkce seznamu nejsou úplně kompletní:

  • neexistuje žádná funkce foldr, funkce array_reduce() poskytuje foldl
  • array_map() by měl předat klíč ve druhém argumentu, stejně jako array_walk()
  • array_map_keys() by mohla být užitečná pro úpravu klíče
  • porozumění seznamu je velmi neohrabané, range(), array_fill() a array_fill_keys() zpracovává pouze tolik případů a array_filter() je samostatný

Nesnažím se přenést PHP do Haskellu), ale PHP je často používáno pro manipulaci se strukturou datových typů typu seznam a mít v této sadě úplnou sadu nástrojů by bylo užitečné.

5
Orbling

Přetížení operátora:

$result = $MatrixA + $MatrixB * $MatrixC;
5
MicE

Podpora velkých souborů. Pěkně prosím?

Viz http://bugs.php.net/bug.php?id=27792 (i když může existovat i více oblastí/funkcí, které vyžadují pozornost).

4
Don MacAskill

Přidejte výjimky místo produkce E_WARNING ... Je velmi nepříjemné, že nemohu použít něco jako:

try{
   $f = fopen('asd', 'r');
   flock($f, LOCK_SH);

   while(!feof($f)){
       echo fread($f, 512);
   }

   fclose($f);

}catch(IOException $ex){
   echo 'Oops, something wrong: '.$ex->getCode();
}

V současné době samozřejmě není moc praktické, ale je velmi nepříjemné dostávat:

VAROVÁNÍ

VAROVÁNÍ

VAROVÁNÍ

a nemůžu ovládat tok kódu bez zápisu vlastního error_handler a šňupání řetězců, která chyba byla způsobena (povolení, nesprávný název souboru nebo cokoli jiného; nevím o jiných zdrojích chyb zde), abych házel správnou výjimku .

Doufám, že nemusím vysvětlovat, proč je to důležité.

PHP se před časem stalo objektově orientovaným a my, programátoři, kteří používají PHP, se těšíme na OO funkce, nezavádějící "goto" ... Když jsem zjistil, že se to opravdu stalo, myslel, že to byl dubnový blázen.

4
eRIZ
  1. Upevněte model objektu - všechny objekty rozšiřují základní třídu Object. Třída Object by implementovala (mimo jiné) všechny magické metody (takže už nebudou magické!)

  2. Přesunout rozšíření do jejich vlastních jmenných prostorů - zrušte globální jmenný prostor $conn = new \MySQLi\Connection();

  3. Zrušte funkci spl_autoload()! Vážně, je to pravděpodobně jedna z největších funkcí PHP a také nejužitečnější současně). spl_autoload Je výchozí autoloader, který podporuje jmenné prostory a více přípon souborů, ale z nějakého neznámého důvodu vyžaduje, aby názvy souborů byly sníženy. Existuje hlášení o chybě je vyplněno , ale zaměstnanci odpověděli, že to neopraví kvůli zpětné kompatibilitě. Správně ... to není jako každý rámec je dodáván s vlastním autoloaderem, protože výchozí je ochromen!

4
Mchl

Přineste drobnou podporu na nejnovější verzi a zahrňte ji do standardních sestav, nejlépe zapnuto ve výchozí konfiguraci http://wiki.php.net/rfc/taint

Zabránilo by to útokům injekcí XSS a SQL tím, že by lidé správně kódovali.

4
rjmunro

Anotace pro PHP by bylo skvělé, jedna funkce, která by vynikla pro nadcházející roky. Tato funkce pomůže psát velké rámce s čistým kódem.

3
user10916

Chtěl bych vidět klauzuli else pro while, for a foreach. Např.:

while (/*condition*/) {
   /* display each result */
}
else {
   /* condition was never true; display "no results found" message */
}

Blok else se provede, pouze pokud podmínka pro while byla nikdy true.

To by umožnilo, abyste nemuseli sledovat booleovské vlajky a možná vám to pomůže přemýšlet o hraničních případech a možných chybových stavech.

3
Macneil

Nezbavte se krátkých otevřených značek, zejména echo one = (. Toto:

<?=$myvar?>

... je mnohem lepší než tohle:

<?php echo $myvar;?>
3
dukeofgaming
  1. Jednoho dne bych ale rád viděl datový typ - také se mi líbí jednoduchost, že se nemusíme zabývat datovými typy, je to pro mě dvojsečný meč.
  2. jmenné prostory!
  3. Přetížení volání funkcí s různými podpisy metod
  4. Lepší podpora pro testování jednotek a vkládání kódu, PHPUnit je úžasný nástroj, stejně tak rámec pro vkládání kódu Symfony dělá zázraky ... ale všichni přicházejí s vlastní křivkou učení.
3
cdnicoll

Zdá se, že nikdo nezmínil volitelný typ bezpečnosti.

Bylo by skvělé mít možnost psát kód takto:

<?php
$someVariable = 123;
$someVariable = "Hello World";

int $anotherVariable = 123;
////$anotherVariable  = "Hello"; // This must cause runtime exception.
////int $lastVariable = "World"; // This must cause it too.
?>

Další příklad:

<?php
// Current style (which must remain).
function SayHello($howManyTimes)
{
    if (!is_int($howManyTimes))
    {
        throw new Exception('Argument $howManyTimes is invalid. An integer was expected, instead of ' . gettype($howManyTimes) . '.');
    }

    echo str_repeat('Hello', $howManyTimes);
}

// New, optional, style, allowing to have a shorter code.
function SayWorld(int $howManyTimes)
{
    echo str_repeat('World', $howManyTimes);
}

SayHello(123);
SayHello("Hello World");

SayWorld(123);
////SayWorld("Hello World"); // This must cause runtime exception.
?>
2
Arseni Mourzenko

Povolit jmennému prostoru soubor z volání zahrnout, něco takového

include('mytemplate.php', 'MyNamespace');

nebo

include 'mytemplate.php' use MyNamespace;

A začněte nám umožňovat importovat („používat“) jmenné prostory bez předpony:

use OtherNamespace as self;

(namísto nutnosti importovat každou jednotlivou třídu, aby byla použita bez předpony oboru názvů)

2
user11122
  • Neblokující dotazy SQL (Jako vložte nějaký protokol, ale nečekejte na výsledek dotazu)
  • Paralelní dotazy SQL

jenom sen

2
Erlango

Generátory. Stejně jako v Pythonu, s výnosem.

2
ts01

Schopnost vrhnout výjimky v __destructor nebo __toString. A skutečně existuje nějaké vysvětlení, proč to není možné?

2
ts01

Bylo by hezké mít možnost nastavit primitivní typ (bool | boolean, int | integer, float, double, string, object) parametru v metodě, jak je pole povoleno.

Příklad:

  • proud:

    class HttpResponse {
    public function __construct($version, $statuscode = HttpStatus::OK, HttpResponseHeaders $headers = array(), $body = '');
    

    }

  • naděje:

    class HttpResponse { public function __construct($version, integer $statuscode = HttpStatus::OK, HttpResponseHeaders $headers = array(), string $body = ''); }
    

Myslel jsem také, že mám Assertovu statickou třídu, která může být užitečná.

2
user11251

podpora typu hinting pro všechny typy a _toXXX magické metody pro každý typ možné. (php běžné použití posunuje IMHO spíše k omezení typu žonglování/s některými výjimkami, jako je konverze float <-> int /)

2
ts01

Jednoznačně přetížení metody pomocí označení typu k rozlišení podpisů metody. Ještě dále bych rád viděl nějaké "atributy" stylu ASP.NET, aby mé akce řadiče v PHP MVC rámci mohly vypadat takto:

/* [HttpGet] */
public function login() {}

/* [HttpPost] */
public function login() {}
2
TaylorOtwell

PHP potřebuje neměnnou třídu řetězců Unicode. Zajištění platnosti vstupních řetězců, normalizovaných UTF-8 a zachování jejich platnosti by mělo být triviální.

$str = new Utf8String('āll īs ōk');
$str = $str->ucwords(); // Āll Īs Ōk
$str = $str->strtolower()->toAscii(); // all is ok
(string) $str; // UTF-8 bytes

Udělal jsem prototyp na základě PHP-UTF8 .

2
Steve Clay

Nativní literály regulárních výrazů, citace ve stylu Perl qw{}, qq{} A q{}.

Metoda zřetězené metody volá pro všechny objekty: $object{ ->method1(); ->method2(); ->getPerson()->getName(); }

Výraz příkazu: ({echo $a; $a = $a + 1; $a})

DŮLEŽITÉ, NELZE KONFIGUROVATELNÉ, NEMŮŽE BÝT VYPNUTO short_open_tags. Pokud nejsou konfigurovatelné, PHP kód bude více přenosný. Viz wha včetně ERB - styl značky

1
Ming-Tang
  • Chtěl bych vidět nějaký nativní způsob, jak nastavit open_basedir ve virtuálních hostitelích automaticky na základě názvu domény, aniž bych musel konfigurovat jednu direktivu na hostitele (podobná záplatě Jason Greene, ale nativní).

  • Prosím, globály pro celou aplikaci! Po inicializaci budou globální proměnné aplikace dostupné pro všechny skripty php.

  • Nějaký způsob, jak uvolnit relaci pro jiná vlákna, bez jejich uzavření:

 session_start (); 
 $ _ SESSION ['favcolor'] = 'white'; 
 session_flush (); // relace je nyní odblokovaná, takže ji mohou použít jiná vlákna 
 // obrovská smyčka ... 
 $ _ SESSION ['tast'] = 'sweet'; // relace automaticky znovu blokuje 
 session_close (); 
  • Možná by nějaká mezipaměť na disku byla pěkná, takže můžeme PHP skripty předkompilovat ručně pro rychlejší spuštění. Podobné jako v mezipaměti paměti, ale se soubory na disku a manuálním generováním (pravděpodobně s použitím nějaké nové přípony souboru).

  • Také něco podobného <? Php = $ variabilní?> Jako zkratka k <? Php echo $ variabilní; ?> by bylo pěkné (jako v asp tagech, ale s krátkými/asp tagy zakázány).

1
Bacco

a samozřejmě get_shutdown_functions () a unregister_shutdown_function (). V současné době neexistuje způsob, jak k tomu přistoupit. A obecně, některá abstraktní podpora pro zpětné ukládání do paměti - něco sjednotit spl_autoloads, funkce vypnutí, popisovače chyb (v současné době nelze stohovatelné, ale možná ...) atd. Druh register_callback ($ zpětné volání, $ stack) a tak dále, s některými předdefinované zásobníky ('autoload', 'shutdown', 'error' ...), které volá php nebo samotný uživatel.

1
ts01

přidávání obálek objektů pro rozšíření pomocí zdrojů (curl, ftp, Gd2 ...). Jako

 $oFtp = new Ftp();

 $oFtp->connect();

 $oFtp->close();
1
ts01
  • lexikální rozsah pro lambdy (pomocí jiného klíčového slova než funkce) (nebo blokováním syntaxe pro vytvoření správného lexikálního rozsahu?)
  • učinit lambdy ve vlastnostech objektu na vyžádání
  • vždy znamenat středník s lambda zavíracími rovnátkami
  • kurva přidat use () pro normální funkce !!
  • zvláštnosti
  • schopnost zachytit instanci/is_a ()
  • generátory
  • otevřít Výjimku pro úpravy za běhu
  • funkce, která kontroluje rozhraní bez implementace
1
alan blaire

Moje první dvě nepříjemnosti se netýkají PHP, ale s jeho předpokládanými zvyklostmi.

  1. 'Přípona názvu souboru' pro kód knihovny (např. PEAR/Horde/Zend/atd.) By měla končit na .phps Místo .php. Výhodou je to, že jasně odděluje spouštěcí kód a kód, který má obsahovat, a že veškerý (váš) kód je volitelně docela dobře čitelný/prohledávatelný ze serveru. Jako bonus lze funkci spl_filename_extensions() použít v autoloaderu pro pohodlí ostatních.

  2. Konvence (v dokumentech) je taková, že :: Se používá jak pro statické, tak i pro instanční metody, byl bych vděčný, kdyby použili :: Pro statické a -> Například věci. Jako dobrá konvence bude stále existovat prostor pro chyby týkající se interpretace, ale je to alespoň jasnější.

Abychom jmenovali alespoň některé, chtěl bych také vidět následující:

  1. Reflexe 's getDocComment (nebo možná další varianta jména nebo argumentu) by měla být liberálnější a také získat pouze první komentáře (do mezery) nad uvedeným typem. Jinými slovy: Nelíbí se mi podrobná (přečtená: řádková konzumace) dokumentace, zatímco já opravdu chci být schopen poskytnout holé minimum v jakémkoli typu komentáře: //, # nebo /* ... */.

  2. Seznam použitých jmenných prostorů, např. getdefinednamespaces().

  3. Chování „nedefinovaných konstant“ by mělo být možné změnit ini směrnicí, např. prázdný řetězec nebo fatální chyba. Nikdy by to však nemělo být implicitně transformováno na řetězec! (je to jako; v javascriptu).

  4. Konstanta __CLASS__ By také měla automaticky fungovat takto (nazývaná staticky) stdClass::__CLASS__ == '\stdClass'. Jinými slovy, místo odkazu na třídu řetězcem chci použít třídu a její magickou konstantu __CLASS__. (ano, je to idefix)

  5. Zadejte metody odlévání a magie __fromType($instancetype) and __toType($type). Objekt lze tedy přetypovat na celé číslo: $y = (int) $x nebo na jiný objekt $y = (BeanWrap) $x. Nicméně implementace tohoto znamená, že z dvanácti dostupných obsazení, která pokrývají osm různých typů, jména těchto obsazení již nemohou být použita jako classnames (např. Int, binary, boolean).

1
23JUL

Když jsem viděl toto vlákno, myslel jsem si, že by bylo užitečné zmínit některé články, do kterých jsem narazil.

  1. Něco jako Groovy Groovy? operátor v PHP: http://justafewlines.com/2009/10/groovys-operator-in-php-sort-of/
  2. Vylepšit uzávěry: http://justafewlines.com/2009/10/whats-wrong-with-php-closures/
1
Alexey Shein

Být dostatečně moudrý, aby ne porušil zpětnou kompatibilitu. Naučil jsem se existenci goto jako klíčového slova tvrdě, používal jsem ho jako název metody, takže aktualizace mého kódu pro php 5.3 trvala 2 nebo 3 hodiny.

Něco jako role pro třídy by bylo dobrým doplňkem systému objektů. Nic složitého.

class abc { use xyz::method; use uvw::__all; }

To by vybralo metodu metody ze třídy xyz a všechny metody ze třídy uvm.

Volání konstruktoru by mělo být použitelné jako objekt hned po vytvoření.

new goodie()->youp();
1
giftnuss
  1. Nechejte skaláry zacházet jako s objekty. Pokud se pokusím udělat $ skalární-> toLower (); proč mi řekni, že se mýlím? Proč to nejen dočasně přetypovat na něco jako „skalární“ typ objektu a poté přejít na „nedefinovanou metodu“ (možná to neuděláte jako null)?

  2. Odebrání prostředků z uživatelského prostoru. PHP má nyní objekty. Všechno, co je nyní zdrojem, může být v obálce objektu, který ho skryje jako soukromou vlastnost. Možná bude potřeba přidat funkce pro __sleep () a __wakeup (). Většina zdrojů lze snadno znovu vytvořit v „podobném“ stavu. I když to nelze, objekt PDO nelze serializovat: Předpokládám, že totéž lze provést s jinými objekty.

  3. Nechte skutečnou komunitu PHP komunita dělat hlasy s jejich kódem: dovolte nám předefinovat stávající metody, třídy a funkce. Špatný kód se bude hnit, stejně jako v Javascriptu. pomocí PHP zjistěte, co potřebují, místo toho, abyste museli neustále hádat. Funkce a funkce používaly/potlačovaly nejpravděpodobnější potřeby, které je třeba zvážit.

    To má také vedlejší účinek spočívající v zapojení komunity PHP) s problémy UTF (doufejme, že UTF-8). Namísto nastavení celého systému, které zapíná nebo vypíná unicode, PHP vývojáři mohou přepsat funkce, které potřebují jen pro svou aplikaci.

  4. Vytvořte _ implicitní oddělovač oboru názvů. Lidé ji používají od PHP5, nechte lidi stavět svůj kód místo přepisování, pokud pro PHP 5.3.) Nevím, jak je to složité. Vím, že na začátku je nějaká myšlenka na kód, který dělá názvy tříd jako Zend_Exception: Povolte to, vývojář bude mít vždy přístup k tomu jako Zend_Exception nebo\Zend\Exception a nikdy Výjimka. Zacházejte s celým jménem namísto pouze s částí jednoho.

  5. OOP: vezměte několik rad z Javascriptu/ActionScript/Pythonu. Znaky vypadají slibně, ale dynamická změna typu za běhu by byla úžasná.

  6. Vlastnosti: Vidím, že rozhovory jsou v dílech o vlastnostech, prosím, implementujte je dynamicky. PHP má být dynamický jazyk. Měli bychom být schopni definovat vlastnosti (téměř vše) za běhu.

  7. Konstanty považujte za to, k čemu slouží: globální proměnné. Třídy/funkce/jmenné prostory jsou pro tento účet vhodné. Možná, když si všichni začnou uvědomovat, že právě teď jsou všichni globály, bude více nápadů, jak vyřešit problém, že existuje tolik globálních proměnných/konstant.

  8. Kompilace JIT: Javascript to dokáže a je super rychlý. PHP je jedním z mála pozadu v tomto.

  9. PHP by mělo být optimalizováno pro "Hypertext", přesto neexistuje jednoduchý způsob, jak uniknout výstupu jako takové. Osobně bych předefinoval 'tisk', abych htmlspecialchars (). Celkově to může být jen princ nebo echoh.

  10. Zjednodušte php.ini. php.ini je pro správce systému, nikoli pro vývojáře. Odstraňte nekompatibility krátkých značek, opravte je nebo je odstraňte. Je to nepříjemné pro správce systému, aby mohli zapnout/vypnout funkce jazyka pro celý systém. A obejít je při pokusu o distribuci softwaru.

  11. Povolit, aby vývojář PHP vývojář existoval po ukončení cyklu požadavků (pro FastCGI a Apache). Vystavte to přes API. Umožněte správci systému to zakázat nebo omezit.) do 10 sekund nebo ztratí svůj trvalý stav).

  12. Udělejte PHP obecný programovací jazyk.) Značky <? Php jsou nepříjemné: při detekci! #/... to není nutné!.

  13. Krátce pro vytváření objektů {} a polí [], Taje se podíváme na PiHiPi , implementují to a spoustu dalších jednoduchých syntaktických cukrů.

    14: Povolit [] přístup k vlastnostem a funkcím objektů. Funkce a třídy jsou nyní prvotřídní občané, že? Vytvořte [] de facto způsob (jako javascript/actionscript) pro dynamický přístup k věcem na objektech.

  14. Povolit PHP kód být PHP moduly). Neměl bych se učit C, jen abych zpřístupnil svou knihovnu v celém systému ve více procesech. PHP komunita na to přijde více).

  15. Namísto převzetí nápadů z jazyka Java/C je vezměte více z dynamických jazyků, jako je Javascript, Actioncript a Python. Podrobnější funkce jsou uvedeny níže.

  16. Závažné chyby: Proč většinu chyb stále nelze odstranit? Miluji představu o chybách protokolování v souboru protokolu (implementovaném na velmi vysoké úrovni). To, co se mi nelíbí, je vždy slyšet o „bílé stránce“. Dělám spoustu kontrol a deklarací v kódu, abych jim zabránil: ale když někdo předá mé funkci null namísto předmětu, Bůh zakáže, že PHP se může zotavit z takové katastrofické situace bez toho, aby já udělám is_null () sám. Jistě je to chyba, zdá se hloupé, že většina ostatních jazyků to nazývá NullReferenceError/Exception, které lze řešit a prezentovat s více než jen bílou obrazovkou.

    Přinejmenším přestaňte přidávat fatální chyby. Mám možnost upgradovat mnoho serverů, které běží PHP= 5.2, ale nemůžu: protože nemám čas projít ~ 200 webů na každém serveru, abych opravil starý kód) . Čím méně nových fatálních chyb přidáte, tím je pravděpodobnější, že se lidé dostanou na palubu s novými verzemi PHP.

    Odstraňte z jazyka co nejvíce fatálních chyb. PHP má být dynamický jazyk: proč se může každý další jazyk zotavit z většiny chyb PHP považuje za fatální? Programátoři dokážou chyby vyřešit, ale ne pokud program násilně zemře po tom, co většina jazyků považuje za NullReferenceException.

  17. Umožněte obnovení výjimek. Takže můžeme snáze kombinovat výjimky a chyby.

  18. (Nejnáročnější a nejpravděpodobnější) Oddělte jazykovou diskusi, diskusi o API/modulu a diskusi o tlumočníkovi. Neměly by být tak integrované jako právě teď. Problémy se současným tlumočníkem by měly být vyřešeny jako poslední. Pypy/Parrot/JVM podporují více jazyků. V8 ne, ale je natolik rychlý, že některé pracují na kompilaci dalších jazyků do JavaScriptu, aby fungovaly na V8 a využívaly jeho schopností.

    Jako interpret/runtime/vm jsou rozvojové cíle poněkud odlišné od jazyka. S PHP to vypadá, jako by byly stejné. Takže lidé, kteří se pokoušejí rozvíjet jiné tlumočníky, mají těžké udržet krok s diskuzemi, když je celá diskuse o jazykovém designu smíchána s diskusí s tlumočníkem PHP.

    Jako tlumočník cítím, že čím více jazyků tlumočník podporuje, tím lépe. Proč nemůžeme mít <? Python nebo <? Javascript nebo <? Actioncript. Už mě nebaví přepisovat kód v jiném jazyce, abych ho tam mohl použít. Někteří se to již snaží udělat, pravděpodobně by se shromáždili podporu z jiných oblastí komunity.

1
Reece45

Moje funkce číslo jedna by byla

operátoři přetížení

Podle mého názoru lze jednu opakovanou funkci požadovanou zde, jmenovitě nativní typy jako objekty, opravit vytvořením vlastních tříd obalů. Pro své projekty jsem vyvinul objekt arrayData, objekt stringData, objekt intData atd. ... To řeší:

  • Silné psaní: protože se jedná o vlastní třídy, lze je vynutit
  • Přetížení typu: Do své třídy arrayData mohu přidat jakékoli metody, které potřebuji
  • Převod typu: každá z mých tříd má -> toArray (), -> toInt (), -> __ toString () metody atd.
  • únik html v šablonách (řetězce jsou třída userStringData, která rozšiřuje třídu stringData).
  • hodnoty jsou vždy předávány odkazem, pokud není uvedeno jinak
  • vytvoření intData ('řetězec') vyvolá výjimku.
  • atd. (seznam výhod je stále velmi dlouhý)

Imho, to je výhodnější než nativní typy jako objekty, protože můžete mít přesný počet metod, které potřebujete, a volat je podle vašich představ.

Co mi ale chybí, je schopnost používat nativní operátory na mých objektech. Díky arrayAccess mohu použít operátor []. Ale nemůžu použít "+", "-" atd. Pokud bych mohl, mohl bych udělat stringData + stringData (ekvivalent $ string. $ String) nebo stringData-stringData (ekvivalent str_replace ($ str, ' ', $ string)) nebo porovnejte mé typy s ">" a "<=" ...
Moje současná implementace používá $ intData-> add ($ n), $ intData-> subtract ($ n) atd. Těžkopádné, zejména ve funkcích, kde můžete očekávat nativní int nebo intData objekt. Což znamená, že se musím zkontrolovat s instanceOf uvnitř každé funkce.

Jinými slovy, ačkoli moje třídy jsou připravené, optimalizované a pěkné, dokud nedokážu přetížit operátory, nejsou ničím jiným než důkazem konceptu. Jejich použití ve skutečném projektu je nepříjemné.

0
Xananax

Vystavte počet referencí zval. (Ano, mohli bychom použít xdebug_debug_zval , ale povolit Xdebug na živém webu, ick.) Příklad použití: aktivní objekt objektu záznamu - máte modely, které odpovídají externím zdrojům (jako jsou řádky databáze), a jsou zodpovědný za úpravu těchto zdrojů. Mít dvě samostatné reprezentace objektů pro stejný zdroj by bylo špatné (ztráta dat v důsledku konfliktních zápisů atd.), Takže potřebujeme nějaký druh mezipaměti, která může vrátit model pro požadovaný zdroj, pokud již byl načten. To by však zabilo sběr odpadu: poslední odkaz na objekt modelu by vždy zůstal v mezipaměti, takže by iterace pomocí velké sady zdrojů, jako je velký dotaz na databázi nebo velký adresář, rychle pohltila paměť. Tomu by se dalo zabránit, pokud by bylo možné v úložišti objektů zkontrolovat, zda existuje pouze jediný odkaz na uložený objekt (samotný úložiště), a pokud je tomu tak, zničit jej.

0
Tgr

Potřebuji nějaké erlang funkce v php:

  • načítání horkého kódu
  • atomy
  • párování vzorů (uveďte název funkcí, odpovídající příkaz jako: případ)

Práce s bytecode: ukládání, načítání, odebírání atd. ...

Flexibilní systém vkládání

0
Dan

Líbí se mi pokrok a škálovatelnost php v posledních dnech.

Nové funkce zavedené v Java) dělají věci složitější, než aby byly jednoduché.

požadavek 1: zařízení db-connection-pool jako další knihovna.

požadavek 2:

Žádám o reverzní Ajax nebo programování komet nebo RTMP zařízení jako vestavěnou knihovnu. Tyto jsou již vyvinuty pro .net, Java, python a Perl od dojo Foundation

Máme podobné věci v php, ale ne kompletní řešení.

  1. V SPL je také podpora pro vzor pozorovatele. ale nejsou řádně zdokumentovány.
  2. Framework Xajax (dobrý, ale vyžaduje přepracování aplikace)

tak zatím ahoj.

0
Shashank

pár věcí, které by udělaly můj den

  • Konvenční pojmenování konvencí pro vestavěné funkce.
  • Zadejte rady pro řetězce a numeriku
  • Vrácení typu
  • E_STRICT je ve výchozím nastavení zapnuto
  • Rysy, mixiny a vícenásobná dědičnost
  • Všechno je objekt (tj. Rubínová čistota)
  • Přidejte podporu :: do oborů názvů
  • Lepší podpora oken
  • Testování mimo krabici
  • Lepší dokumentace pro underworkings exec ()
  • Redesign php.net s live-search
  • Xdebug jako funkce mimo krabici
  • Vylepšení přenositelnosti PEAR - přenositelnost Ruby drahokamy by měli vědět)
0
Grayson

Opravdu bych chtěl mít anotace .. afaik, že RFC bylo zrušeno.

0
crystal88_
  • Podpora UTF-8
  • Udělejte jazyk plně OO, půjčujte si koncept Ruby a Python), že všechno je objektem. Rád se mi líbil autoboxing rfc. Nicméně dává příliš mnoho svobody pro vývojáře, což není tak dobré. Ale s určitými omezeními by to mohl být pěkný doplněk k vývoji jazyka.

$ x = pole (5, 60, 50, 50); $ x-> mapa (funkce ($ i) {návrat $ i * 2;}) -> Push (10);

$ p = "nějaký řetězec"; $ q = $ p-> podřetězec (0, 10);

atd.

Podle mého názoru to lze provést bez přerušení současných globálních funkcí. Většina z nich se však stane zbytečnou a v průběhu času by mohla být ukončena.

  • Krátký zápis pro pole by byl pěkný, ale pro jazyk to není rozhodující.
0
Josh Scott

Bylo by hezké používat třídu, která rozšiřuje iterable ve smyčce foreach, kde předáte odkaz na smyčku:

 foreach (& $ myclass jako $ me) {
 echo $ me; 
} 

Nestrávil jsem mnoho času zkoumáním, proč to v současné době nefunguje, možná to souvisí s tím, jak fungují iterables, nešetřil jsem mnohem víc, než jen si všiml, že to nefunguje.

0
gabe.

Rychlejší volání funkce

Máme call_user_func($f,$a1,$aN), ale bylo nahrazeno $f($a1,$aN). Nic pro call_user_func_array($f,$args) však neexistuje.

Mým návrhem je vytvoření specifické syntaxe jazyka, například $f{$args}. Důvodem, proč by se každý měl zdržovat míli daleko od call_user_func*, Je to, že vypadají velmi pomalu a ošklivě v tom smyslu, že existují lepší alternativy.

Syntaxe úpadku objekt

Právě teď, chcete-li vytvořit objekt za běhu, potřebujete: (object)array('prop'=>'value');. Podle konvence bychom také měli mít object('prop'=>'value');. Krátké syntaxe by byly také užitečné, podobné JSON.

Be-all-end-all magická metoda pro typy

Právě teď máme __toString() a mnoho z nich navrhlo __toInt/__toFloat/Atd. Moje rada by byla implementace __toType() nebo __typecast(), která jako první parametr předá požadovaný typ dat, např .:

class Test {
    public function __toType($type){
        switch($type){
            case 'integer':
                return (int)$this->age;
            case 'string':
                return $this->age.' years';
            default:
                throw new EUnsupportedTypeException();
        }
    }
}

Pokud bychom chtěli být konkrétnější, mohli bychom přidat další argument za $ typ, konkrétně $ class. Takže můžete: if($class=='person')return new Person($this->age);

rčení typu dat v foreach

V současné době můžete určit datový typ a PHP argument funkce, například:

public function say_hello_to(UserClass $user){
    $this->say('Hello, '.$user->name.'!');
}

Bylo by skvělé to udělat také v foreach:

public function on_enter_office(){
    foreach($users as UserClass $user) // <- See UserClass here?
        $user>say_hello_to($this);
}

Aktuální „oprava“ používá uzávěr, jako například:

public function on_enter_office(){
    $users->each(function(UserClass $user){
        $user>say_hello_to($this);
    });
}

Oprava vyžaduje více zdrojů, více psaní a zmatení rozsahu, proto proč nativní řešení usnadní, čistší a pravděpodobně rychlejší než aktuální oprava.

Podmíněné definice

Pravděpodobně to nebude pro mnoho lidí užitečná funkce, ale je to skvělý způsob, jak udržet běžící kód na minimu, i když je kompatibilní se starými systémy, což zrychluje provádění. Zvažte následující kód:

if (! function_exists ('json_encode')) {function json_encode ($ value, $ options = 0) {// starší kód}}

  • Sekce // legacy code Je stále analyzována, takže jakékoli chyby v ní způsobí ukončení PHP).
  • Jeho rozbor také zpomalí PHP, i když to vůbec nepotřebuje).
  • Tento kód není pro vývojáře intuitivní
  • Jakékoli IDE parsovací stroje) budou zmateny, protože ignorují příkazy a nakonec uvedou funkci dvakrát.

Oprava? Podmíněné kompilace:

#if PHP_VERSION<5.2
function json_encode($value, $options=0){
    // legacy code
}
#endif
0
Christian

zahrnují lepší podporu hypertextových odkazů, tj. metodu funkce/třídy, kterou lze použít ke změně aktuálního uri prohlížeče. nebo vytvořit úplně nový. pomocí $ _SERVER ['REQUEST_URI'] || $ _SERVER ['PATH_INFO'], abyste porozuměli požadovanému prostředku. Mohlo by to usnadnit vývoj aplikací REST. (podle rfc je UriScheme a jeho implicitní implementace schématu, možná bude možné implementovat další UriSchemes rozšiřující UriBase)

Poskytněte něco jako třídu UriResource, což umožňuje vyžadovat malé úryvky funkčnosti způsobem, který by také mohl těžit z http-požadavků od klienta.

Proveďte funkci, kterou lze volat před a po šabloně, a povolit zkratky mezi těmito dvěma voláními funkcí. Mezi těmito voláními funkcí jsou zpřístupněny pouze proměnné předávané prvnímu volání funkce (jako asociativní pole (pomocí výpisu)). To by mohlo usnadnit vývoj šablon v samotném php (rámec bez rámce). Rámec no-framework PHP MVC framework)

Celkově vzato si myslím, že mnoho php frameworků tam má určité podobnosti, které by se daly snadno integrovat do php běžným způsobem.

ale whoami :)

0
immeëmosol
  1. Neměnné hodnotové objekty
  2. Anonymní třídy a/nebo třídy jako objekty
  3. Vestavěný objekt ekvivalentní datovému typu řetězce (zmíněno výše)
  4. Anotace nebo Pythonoví dekoratéři
  5. Singletonové objekty jako v Scale
  6. Výchozí chyby jako výjimky (uvedené výše)
  7. Podpora UTF8
  8. Odstranění globální atd
  9. Princip sjednoceného přístupu - jeden způsob, jak volat metody objektů a manipulovat s vlastnostmi (viz Scala)
0
sokzzuka