🚀 go-pugleaf

Użytkownik "ethouris" <ethouris@gmail.com> napisał w wiadomości

> > PS: Jezykiem beztypowym to jest np Tcl.
> >       Tam wszystko jest stringiem.
> Bzdura.
>
> Język Tcl jak najbardziej posiada typy (z tym tylko, że w zakresie
> języka nie można tworzyć własnych). Zasada EIAS tak naprawdę polega
> tylko na tym, że każdy obiekt Tcl-owy (a więc należący do jednego z
> Tcl-owych typów) jest automatycznie serializowalny, tzn. zawsze może
> być przekonwertowany na string i odwrotnie.
> No i oczywiście nie można
> tych typów jawnie weryfikować w programach.

Taaa, nie moge tworzyc nie moge werifikowac, w ogole ich
nie widze
No to gdzie te typy ?

Sektor przestan prosze pierdzielic od rzeczy.
Typow w Tclu nie ma i nie bylo nigdy.
W Tclu _wszytsko_ jest stringiem i gadanie o jakis
wewnetrznych optymalizacjach majacych na celu
poprawe szybkosci swoistego _autointerpretera_
 jakim jest Tcl to jawne wprowadzanie ludzi w blad.
Nawet te optymalizacyjne zabiegi sa dopiero od Tcl8.0
a w Tcl7.6 ich jeszcze nie bylo.
Natomiast Tcl7.6 i 8 sa zgodne w sensie jezyka.

> Aczkolwiek jest to zupełnie niepotrzebne, bo w Tcl-u si
> ę po prostutego nie robi.

Nie robi sie bo sie po prostu nie da.
Ni ma na czym badac tego typu.

> Jeśli np. potrzebujemy wykonać operację dodawania na
> dwóch wartościach, a jedna z nich jest stringiem nie konwertowalnym na
> liczbę, to leci wyjątek (note: odmiennie, niż np. w Perlu, w którym
> "jeden" == "dwa" zwraca true).

Ta , leci wyjatek bo parserek czyli komenda [expr ]
nie umie zewaluowac argumentu.
Ten argument jest jednak zwyklym stringiem.
Nie ma tak zadnego tworzenia obiektow typu int long
string itp.
Po prostu jest zwykle parsowanie _stringu_
Bo w Tcl _wszytsko_ jest stringiem.

> ale i w takim języku nie widzę koniecznej potrzeby posiadania
> możliwości sprawdzania typu.

Sektor prestan truc juz bez sensu.
W jezykach bez statyvznej kontrolo typow trzeba
_szczegolnie_ o ta kontrole zadbac.

Poczytac sobie o Pythonowych rzeczach
od prosciutkiego (a i tak dajacego o wiele wieksze
mozliwosc niz "wypasiona" kontrola typow w C++):
typecheckera:
http://oakwinter.com/code/typecheck
a wnim tutorial i manual

do bardziej zaawansowanych zope.interfaces:
http://www.python.org/pypi/zope.interface/3.3.0
(gdzie masz skrotowa dokumentacje)
to moze zrozumiesz dlaczego takich "niepotrzebnych" rzeczy
istnieje troche dla Pythona.
W praktyce korzysta sie z jednych i drugich
a nawet jeszcze innch (inne - z reguly dekoratorowe
czeckery - wlasnosci/zachowania obiektow).

Tu masz przyklad z brzegu:

@docstring(a="frobination count")
@typechecker(a=Number, b=Number, _return=Number)
@constrain_values(a=range(3,9), b=[4,8,12])
def  foo(a, b):
     # the code

---

floats2_to_float2tuple = typechecker(float, float, _return=(float, float))

@floats2_to_float2tuple
def cartesian_to_polar(x, y):
     return math.sqrt(x*x + y*y), math.atan2(y, x)

@floats2_to_float2tuple
def polar_to_cartesian(r, theta):
     return r*math.cos(theta), r*math.sin(theta)


> W języku skryptowym przykładowo mogę mieć
> "coś" pobrane z jakiegoś źródła i nie interesuje mnie czy w postaci
> liczby całkowitej, czy stringa, ale interesuje mnie jednak, czy to, co
> dostałem, to liczba.
[...]
> Sprawdzam tylko czy [string is integer $liczba] i to mi
> wystarczy.

Taaa.
Czyli sobie zapuszacm znow parserek i sobie patrze czy
sie wywalil.
Jesli sie nei wypierdzielil na [exp $x + 0] to znaczy ze liczba
No ooo w sumie mozna :)

AK