Rano na blogu Wojtka Soczyńskiego pojawił się interesujący wpis wymieniający listę nowości i zmian jakie prawdopodobnie pojawią się w kolejnym dużym wydaniu PHP, oznaczonym numerem 5.4. Należą do nich (wg wpisu Wojtka):
Listę przeczytałem kilka razy (aby upewnić się, że dobrze wszystko zrozumiałem), poszukałem informacji na temat niektórych punktów oraz popadłem w zadumę nad przyszłością PHP. Widać, że język chce iść do przodu, a proponowane zmiany mają mu w tym pomóc. Każdą ze zmian starałem się dobrze przeanalizować i doszedłem do takich oto wniosków.
Podsumowując. W ogólnym rozrachunku zmiany oceniam in-plus. Jeśli tylko udałoby się przyspieszyć rozwój języka, byłbym wniebowzięty.
PHP 5.3.7 Release Candidate 1 jest już gotowe do pobrania i testowania.
Linki:
W ostatnim wpisie na php.internals, Stas Malyshev przedstawił listę zmian i nowości, nad wprowadzeniem których do PHP 5.4 odbędzie się głosowanie. Oto ich lista:
Moim zdaniem każda z tych zmian/dodatków ma duży sens i jest przydatny, chętnie bym wszystkie je widział w kolejnej wersji interpretera. Jedyna rzecz do której mógłbym się przyczepić to punk nr.9 – możliwość ustawienia klasy jako handlera sesji. Wg. mnie ustawienie klasy jest bez sensu i świetnie pokazuje, czym jest tzw COP (Class Oriented Programming). Jeżeli chcemy pisać w duchu OOP (Object Oriented Programming) to handler sesji powinien być ustalany jako obiekt klasy implementującej jakiś interfejs (np. „SessionStorage”).
Co sądzicie o proponowanych zmianach ?
Witajcie ! Jakiś czas minął już od ostatniego wpisu o Scali (3 miesiące), czas więc odświeżyć swoje zainteresowanie i wiedzę na temat tego języka. Dzisiejszym daniem głównym są tzw. case classes. Jest to pewnego rodzaju nowość dla osób przyzwyczajonych do Javopodobnych obiektowych systemów typów. Czym jest więc case class ? Poprzez analogie do innych języków, możemy ją traktować jako typowany kontener na dane – czyli znaną z C/C++ (oraz w troche innym wydaniu w C#) strukturę (struct). Jest to specjalny typ klasy, w przypadku której w konstruktorze deklarujemy listę pól, natomiast kompilator automatycznie generuje nam gettery i settery. Jest to oczywiście wymarzona sytuacja dla wszystkich fanów tego typu „enkapsulacji” (pozdrowienia dla anonimowego „P.” ;P).
Deklaracja:
Kanał ATOM
case class Foo(baz:String, bar:Number)
val myFoo = Foo("test",5)
println(myFoo.baz, myFoo.bar)
Jak można zauważyć w przykładzie nie jest wymagany operator „new” przy tworzeniu nowych instancji case class. Przy okazji pragnę zwrócić uwagę na jeden istotny szczegół – case classa zadeklarowana w sposób pokazany powyżej będzie miała tylko automatycznie wygenerowane gettery. By również settery zostały wygenerowane, należy uzupełnić deklaracje o słowa kluczowe var dla zmiennych, dla których ma być to uczynione.
Przykład:
case class Foo(var baz:String, var baz:Number)
val myFoo = Foo("test",5)
myFoo.baz = "World"
Skoro wiemy już co nieco o case classes, pora powiedzieć kilka słów o pattern matching, by na koniec zgrabnie połączyć oba koncepty. Czym jest więc pattern maching ?
Pattern matching jest to rodzaj uniwersalnego switcha dla języka statycznie typowanego. W Scali używany jest również między innymi w obsłudze wyjątków.
Przykład:
val baz = 10
baz match {
case 1 => println("raz")
case 2 => println("dwa")
case _ => println("default")
}
Jeżeli zadeklarujemy baz jako dowolny typ (Any), mamy możliwość elastycznego matchowania, behold:
val baz:Any = 10
baz match {
case 1 => println("raz")
case "2" => println("dwa")
case _ => println("default")
}
Wyjątki:
def testWyjątków():Unit = {
throw new Exception("houston mamy problem")
}
try{
testWyjątków()
} catch {
case e:Exception => println(e.getMessage)
}
Sytuacja z matchowaniem wyjątków jest podobna jak dla poprzednich przykładów. Smaczkiem jest to, że w nazwach metod (i zapewne klas) możemy używać znaków narodowych – świetna sprawa, przy tworzeniu różnego rodzaju DSL-i.
