Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [Typy danych] Nowy pomysl na klase w PHP
Forum PHP.pl > Inne > Oceny
morpheouss
Witam wszystkich bardzo gorąco.
Nie wiem jak u Was, w innych miejscowościach ale u mnie strasznie parno i pochmurnie zajkby za dosłownie chwilkę miał lunąć deszcz winksmiley.jpg No tak, to nie forum o pogodzie, więc przejde do rzeczy.

Siedziałem dzisiaj na labolatorium programowania wizualnego, zastanawiając się jak rozwiązać pewien problem, a do głowy wpadło mi coś zupełnie innego. Z początku uznałem to za bzdurę i poronioną ideę, jednak coraz bardziej się do niej przekonuję - mimo iż nadal uważam ją za nieco bezsensowną. Popędziłem czym prędzej do domu aby sie nią z Wami podzielić. Mam nadzieję, że zainteresuję Was mój pomysł i wesprzecie moją ideę (propozycje zmian, uwagi techniczne), albo wybijecie z głowy winksmiley.jpg

Jak wiemy w PHP nie ma mechanizmu, który pozwoliłby nam na sztywne trzymanie się danego typu danych (np integer). Mój pomysł może to zmienić. Według tego co wymyśliłem, każda zmienna była by obiektem smile.gif Chcąc stworzyć zmienną typu całkowitego programista używałby np takiego kodu:
  1. <?php
  2. $calkowity = new typy(INT);
  3. ?>

albo np:
  1. <?php
  2. $calkowity = typy::integer();
  3. ?>


Ale co dalej?
Klasa typy dostarczała by szereg metod, które umożliwiałyby odczytywanie i modyfikowanie wartości, przy czym mogłaby generować wyjątki w momencie gdy np do zmiennej typu int będziemy chcieli zapisać łańcuch znaków.
  1. <?php
  2. $calkowity->value(10);
  3. $calkowity->add(5);
  4. $calkowity->getValue(); // zwraca 15
  5. ?>


Dodatkowo planowałem dodać metody konwertujące:
  1. <?php
  2. $calkowity->toString(); // zwraca "15" (string)
  3. ?>

  1. <?php
  2. $string = typy::string();
  3. $string = $calkowity->toString();
  4. ?>


Ale hola, hola... Tzn, że trzeba używać metody getValue, aby wypisać stringa na ekranie? Nie! Może nawet taka metoda nie będzie potrzebna, gdyż:
  1. <?php
  2. public function __toString() {
  3.     return $this->value;
  4. }
  5. ?>


Prawdopodobnie dałoby się tak samo z integerami i innymi typami danych... Do tego dochodziło by także sprawdzanie typów (+ wyjątki) oraz szereg innych metod, jak np getType() - zwracająca typ zmiennej.

Nie wiem natomiast co z tablicami i obiektami - nie zdążyłem jeszcze nad tym pomyśleć tongue.gif Niemniej jednak, przewiduję także typ
'mixed'.

Bardzo zależy mi na Waszej opinii, szczególnie tych bardziej doświadczonych osób i już teraz bardzo dziękuję za wszelkie komentarze.
Kildyt
Ale po co komu coś takiego? PHP to język głównie przeznaczony dla stron internetowych, więc IMHO takie narzędzie to zbędny balast.
Jeżeli chcesz definiować w php typ danych to nikt Ci tego nie zabrania, po prostu nie jest to obowiązkowe i dobrze.

Podsumowując: utrudnianie sobie życie.
wookieb
Zestaw funkcji is_* udostepnia sprawdzanie typu.
Dodatkowo cType i mamy wszystko czego potrzeba.
Crozin
Jak już to:
  1. <?php
  2.  
  3. $int = new Integer();
  4. $int2 = new Integer(42);
  5. //etc.
  6. $float = new Float();
  7. ?>
Cytat
Nie wiem natomiast co z tablicami i obiektami
PHP umożliwia sprawdzanie czy podany parametr jest: tablicą, obiektem (będącym reprezentacją danej klasy/interfaceu) więc nie wiem co chcesz tu robić.

Poza tym również uważam to za niepotrzebny pomysł. A jeżeli zależy Ci na silnym typowaniu... zmień technologię - osobiście polecam Jave.
batman
Kolejny głos przeciw pomysłowi.
Nie chodzi mi o rzutowanie typów, ponieważ tego bardzo mi w php brakuje, ale o samą implementację. Rozwiązanie ~Crozin-a znacznie bardziej by mi pasowało, jednak jest to niepotrzebny narzut obiektów. Ścisła kontrola typów ma jedynie wówczas sens, gdy jest kontrolowana przez kompilator/parser, a nie zewnętrzne klasy.
morpheouss
Cytat(Kildyt @ 18.05.2009, 14:47:28 ) *
Ale po co komu coś takiego?


Wiele osób narzeka na to że w PHP nie ma zgodności typów - nie mam na myśli kontrolę poprzez is_*.

Cytat(wookieb @ 18.05.2009, 14:49:20 ) *
Dodatkowo cType i mamy wszystko czego potrzeba.


To jakiś dodatek? Jeżeli tak, weź poprawkę na to że nie musi być wszędzie dostępny.

Cytat(batman @ 18.05.2009, 15:22:46 ) *
Kolejny głos przeciw pomysłowi.
Nie chodzi mi o rzutowanie typów, ponieważ tego bardzo mi w php brakuje, ale o samą implementację. Rozwiązanie ~Crozin-a znacznie bardziej by mi pasowało (...).


Bardziej zależy mi na ocenie samej idei - sposób w jaki to miało by działać to zupełnie inna sprawa, choć oczywiście wszelkie sugestie są mile widziane.

Cytat(batman @ 18.05.2009, 15:22:46 ) *
Ścisła kontrola typów ma jedynie wówczas sens, gdy jest kontrolowana przez kompilator/parser, a nie zewnętrzne klasy.


Uważam, że to nie ma żadnego znaczenia - i tak błąd dostaniemy dopiero gdy wejdziemy na stronę - bez względu na to co tym zarządza.
Sama idea wzorowana trochę na C++ czy .NET, gdzie mamy np Obiekt->Zmienna.Length(); W tym przypadku byloby to poprostu Obiekt->Zmienna->Length();

Cytat(pyro @ 18.05.2009, 15:44:41 ) *
Ja bym przy tym pozostał winksmiley.jpg


Prosiłem o komentarze - ale nie bezmyślne, tylko takie poparte argumentami.
Crozin
Podstawowe błędy:
1) W PHP niewiele by to dawało. Nie uzyskasz możłiwości przeciążania metod. Podpowiadanie składni przez różne IDE również nie (zresztą one raczej wolą bazować na komentarzach phpDocumentora)
2) Brak rzutowania na obiekt w tle. Przykładowo mając metodę:
  1. <?php
  2. public function doSth(User $user, Integer $sth);
  3. ?>
Nie miałbym możliwości wykonania kodu
  1. <?php
  2. abc.doSth($user, 123)
  3. ?>
Musiałbym:
  1. <?php
  2. abc.doSth($user, new Integer(123))
  3. ?>


Jeżeli już chcesz robić coś takiego, IMO lepiej by było zrobić coś na zasadzie:
  1. <?php
  2. public function doSth(User $user, int $sth);
  3. ?>
Napisać jakiś skrypt, który byśmy uruchamiali przed wrzuceniem plików na serwer, a ten by taki kod zamieniał na:
  1. <?php
  2. public function doSth(User $user, $sth){
  3.  if(is_int($sth) == false){
  4.    throw new ...;
  5.  }
  6.  
  7.  //reszta normalnego kodu
  8. }
  9. ?>
Ale to by było niewygodne i lepiej by było jakby było w formie pluginu do jakiegoś IDE.


Ale i tak uważam, że lepiej pomyśleć nad zmianą narzędzia z PHP na inne jeżeli PHP nie spełnia naszych oczekiwań, bo z tego co wiem, to developerzy PHP nie planują wprowadzić silnego typowania.
batman
Cytat
Bardziej zależy mi na ocenie samej idei - sposób w jaki to miało by działać to zupełnie inna sprawa, choć oczywiście wszelkie sugestie są mile widziane.
Sama idea jest jak najbardziej słuszna. Ale nie ma sensu na siłę symulować zachowania, które nie jest wbudowane w język kosztem ogromnego narzutu obiektów.

Cytat
Uważam, że to nie ma żadnego znaczenia - i tak błąd dostaniemy dopiero gdy wejdziemy na stronę - bez względu na to co tym zarządza.
W przypadku języków skryptowych tak. Ale jeśli weźmiemy pod uwagę języki kompilowane, wówczas błąd pojawi się podczas kompilacji, a nie w trakcie działania.

Dlatego właśnie, że PHP jest tak ubogim językiem, odświeżam wiedzę o .NET, gdzie jest wszystko to, czego w PHP mi brakuje.
morpheouss
Aby rozjaśnić choć trochę co miałem na myśli przygotowałem małą klasę dla boola:
  1. <?php
  2. class pBool
  3. {          
  4.        private $value;
  5.  
  6.        public function __construct($value = false)
  7.        {                                          
  8.                $this->set($value);                
  9.        }                                          
  10.  
  11.        public function getType()
  12.        {                        
  13.                return 'pBool';  
  14.        }                        
  15.  
  16.        public function get()
  17.        {                    
  18.                return $this->value;
  19.        }                          
  20.  
  21.        public function isTrue()
  22.        {                      
  23.                return $this->value == true ? true : false;
  24.        }                                                  
  25.  
  26.        public function isFalse()
  27.        {                        
  28.                return $this->value == false ? true : false;
  29.        }                                                  
  30.  
  31.        public function set($value)
  32.        {                          
  33.                if(is_bool($value))
  34.                {                  
  35.                        $this->value = $value;
  36.                }                            
  37.                else                          
  38.                {                            
  39.                        throw new Exception('Wartosc nie jest typu prawda/falsz');
  40.                }                                                                
  41.        }                                                                        
  42.  
  43.        public function toInt()
  44.        {                      
  45.                return $this->value == true ? 1 : 0;
  46.        }                                          
  47.  
  48. }
  49.  
  50. $bool = new pBool;
  51. $bool->set(true);
  52. if($bool->isFalse())
  53. {
  54.        echo 'moj blad';
  55. }
  56. else
  57. {
  58.        echo 'a jednak jest ok';
  59. }
  60. $bool2 = new pBool((bool) 1);
  61. if($bool2->isTrue())
  62. {
  63.        $bool3 = new pBool(1); // powoduje wyjatek - 1 nie jest typu bool!
  64. }
  65. ?>
Crozin
Cytat
Aby rozjaśnić choć trochę co miałem na myśli przygotowałem małą klasę dla boola:
No to taka implementacja jedyne co robi to utrudnia życie.

$bool->isFalse() może i wygląda bardziej "pro" niż $bool == false, ale poza tym, że pisze się mniej wygodnie, że działa wolniej (co przy setkach zmiennych w całej aplikacji będzie miało znaczenie) to kompletnie nic nowego nie wnosi.
Speedy
Takie coś nie ma sensu w php, bo jest to za luźny język winksmiley.jpg. Jak ktoś chce, żeby jakaś wartość, zmienna, czy cokolwiek koniecznie było konkretnego typu, to może to sobie rzutować. Typy danych można sprawdzać natywnymi funkcjami php, jak już ktoś tutaj wspomniał. Całą tą klasę do boola można załatwić tak:

  1. <?php
  2. if(is_bool($value)) { (!$value) ? false : true; }
  3. ?>
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2024 Invision Power Services, Inc.