Visualizza i risultati del sondaggio: Quanta necessità di uno standard per il PHP?

Chi ha votato
8. Non puoi votare questo sondaggio
  • [ALTISSIMA]Tanta necessità!!!

    2 25.00%
  • [ALTA]Non sarebbe una cattiva idea!

    2 25.00%
  • [NORMALE]Interessante, tuttavia riesco a vivere senza.

    3 37.50%
  • [BASSA]Il PHP potrebbe trarne vantaggi... vedremo!

    0 0%
  • [BASSISSIMA]Preferisco rimanga così.

    1 12.50%
Pagina 3 di 4 primaprima 1 2 3 4 ultimoultimo
Visualizzazione dei risultati da 21 a 30 su 32
  1. #21
    vero PHP è stato sviluppato male: si porta dietro retrocompatibilità varie parecchio pesanti, non ha standard, ha un sacco di funzioni che sono alias di altre funzioni, da una sottoversione ad un'altra possono cambiare i metodi delle funzioni, non è ingegnerizzato a sufficienza, manca di strumenti enterprise...

    discorso vecchio comunque... purtroppo rimane ancora il più diffuso e usato...

  2. #22
    Per come la vedo io, la domanda ha un senso ma solo se posta in un contesto differente.
    Non vedo alcun motivo per uno standard rispetto alle interazioni del linguaggio con strumenti di terze parti, per natura stessa del linguaggio non potrà esserci ed è bene che non ci sia.

    Vedo invece necessità di uno standard per quanto riguarda l'utilizzo, lo sviluppo e la nomenclatura.
    E' impensabile che ancora oggi PHP 5.3 venga sviluppato un po' con funzioni camelcase ed un po' con underscore.

    Allo stesso tempo, non c'è alcuno standard di buona scrittura del codice.
    Chi usa le parentesi in un modo, chi in un altro, chi le costanti le scrive così e chi cosà.

    Zend Framework ci ha provato per primo ad imporre ai propri contributor uno standard ed il risultato è stato a dir poco eccellente. Peccato che siano stati pochi a seguire l'esempio al di fuori dell'ambito del framework.

  3. #23
    Utente di HTML.it L'avatar di Virus_101
    Registrato dal
    Sep 2008
    Messaggi
    2,497
    Gia' il prob inoltre e' che prendiamo ad esempio le funzioni per xml ....

    Beh ci sono fondamentalmete 3 lib diverse :

    SimpleXML
    DOM
    DOM XML

    con tti i casini che ne seguono .....

    Sinceramente nn potevano mettere un layer dom STD e estendere poi tali classi per xml?????
    Le dom Xml nn funzionano ovunque e come detto sopra usano addirittura un namespace diverso.

    Io se potessi passare a linguaggio diverso lo farei subito.


    P.S. vero che php e' il piu' diffuso ma sta perdendo terreno a favore di asp .net ,java e python.
    e se nn fannno qualcosa di serio nelle prossime release tipo reingegnerizzare il linguaggio sbattendosene delle retrocompatibilita' (un po' come il nuovo python) a mio avviso php sara' destinato a cadere. E' solo l'enorme quantita' di spftware gia' fatto in php che lo tiene in vita.

    Mah .... io spero di pter cambiare tecnologie dove lavoro ma la parola spetta sempre al boss.. T_T

  4. #24
    beh le funzioni messe a disposizione del programmatore sicuramente andrebbero reingegnerizzate, come il 90% di php...il problema è che se lo fai perdi la compatibilità col 98% dei siti web esistenti in php.

    Perchè è noto a tutti che ci sono una miriade di convenzioni nelle funzioni php, esempio:
    1) nome_cognome()
    2) nomeCognone()
    3) nomecognome()
    4) nome_Cognome()

    cioè non si può vedere na cosa del genere; si deve scegliere una strada sola. Però pensa se ad oggi si decidesse di usare "nomeCognome()"...abolendo il resto, che succederebbe ai siti? un casino.

    credo che l'unica strada sia quella di portare tutto php a funzionare bene ad oggetti, creando tutte le classi di base necessarie per ricoprire in buona parte l'attuale "parco funzioni" mantenendo però tutta la compatibilità con la "vecchia" versione. Una volta fatto questo passare, quando uscirà una nuova major release...chesso PHP 7, alla nuova gestione del linguaggio strutturato a classi ed abolire la retrocompatibilità!

    Nel giro di due o tre anni si potrebbe arrivare ad avere un linguaggio ad oggetti che presenti una buona struttura di base.
    Administrator of NAMDesign.Net

  5. #25
    Utente di HTML.it L'avatar di Virus_101
    Registrato dal
    Sep 2008
    Messaggi
    2,497
    Quoto.

    Il fatto e' che cmq il prob e' risolvibile, tenendo le vecchie versioni di php come sono ora e facendo una nuova versione come dio comanda che funzioni come si diceva sopra e dichiaratamente NON retrocompatibile. Magari con un fork sul proggetto php.

    Cmq mi sa che una cosa del genere non la faranno mai. E questo a mio avviso causera' un decadimento progressivo nell'uso aziendale di questo linguaggio.

  6. #26
    Originariamente inviato da LeaderGL
    beh le funzioni messe a disposizione del programmatore sicuramente andrebbero reingegnerizzate, come il 90% di php...il problema è che se lo fai perdi la compatibilità col 98% dei siti web esistenti in php.
    Esistono delle cose chiamate warning.
    In pseudocode

    codice:
    function str_to_time(*args) {
      warning("#str_to_time is deprecated and will be removed in PHP 5.xyz. Please use #strToTime.");
      return strToTime(*args);
    }

  7. #27
    Utente di HTML.it L'avatar di Virus_101
    Registrato dal
    Sep 2008
    Messaggi
    2,497
    SI vero come esistono i cosidetti sistemi wrapping.
    Per mantere la retrocompatibilita' potrebbero anche sviluppare un bel sistema di wrapping.

    Quindi ridefinire tutte le funzioni secondo un unico standard e inserire un sistema di wrapping per i vecchi applicativi.

    In modo che pian piano si passi in maniera indolore a poter scrivere codice come dio comanda.

  8. #28
    Perfetto, proprio di questo io parlavo, alla fine pensare di riscrivere del tutto questo linguaggio è un'utopia, meglio cercare di wrapparlo tutto, creando così di fatto uno standard (certo poi dovrebbe essere rispettato da tutti )!

  9. #29
    Originariamente inviato da Nemesis_DaRk
    "fare uscire" 2-3 siti web la settimana secondo voi ha bisogno di un framework, magari con la possibilità di integrare un cms e con supporti "già pronti" per mysql e-commerce eccetera?
    2-3 siti la settimana, immagino l'analisi profonda di requisiti e la complessita' di questi siti ... scegli un CMS poco ciofeca e hai risolto tutti i tuoi problemi
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  10. #30
    così invece di migliorarlo avrai:
    1) i programmatori continueranno a programmare come prima (disabilitando i warnings) per non riscrivere tutto...
    2) php si ritrova il doppio delle funzioni...quelle nuove magari gestite con logica OOP ed i wrapper di "compatibilità"...

    io credo che l'unica strada è fare una versione intermedia che mantenga le attuali capacità e ci aggiunga le controparti oop ben strutturate per poi passare ad una nuova release full oop che segua un criterio ben preciso...delle convenzioni!


    Originariamente inviato da weppos
    Esistono delle cose chiamate warning.
    In pseudocode

    codice:
    function str_to_time(*args) {
      warning("#str_to_time is deprecated and will be removed in PHP 5.xyz. Please use #strToTime.");
      return strToTime(*args);
    }
    Administrator of NAMDesign.Net

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.