2009/4/10 Igor Stasenko <siguctua at gmail.com>:
> 2009/4/10 Philippe Marschall <philippe.marschall at gmail.com>:
>> 2009/4/10 Ralph Johnson <johnson at cs.uiuc.edu>:
>>>> A very interesting article that anyone interested in the topic must
>>>> read: "What To Know Before Debating Type Systems"
>>>> http://www.pphsg.org/cdsmith/types.html
>>>
>>> i disagree that "strong typing" doesn't mean anything.  Weak typing
>>> means "has a type system but it is easy to get around it".  Strong
>>> typing means "has a type system and you can't get around it easily".
>>> Strong typing certainly does NOT mean compile-time typing.
>>>
>>> I agree that "dynamic" (checked at run-time) vs. "static" (checked at
>>> compile-time) is what is important.  C and Fortran have weak static
>>> type systems.  Java has a strong static type system, but only because
>>> casts are checked at run-time, i.e. the static type system has holes
>>> in it but the run-time system patches those holes.  Smalltalk has a
>>> strong dynamic type system; there is no way to run a method on an
>>> object that it doesn't belong to.
>>
>> #valueWithReceiver:arguments:?
>>
> Right. But. Is given method is part of standard?

What does that change?

> IMO this is a dirty hack, which could crash the VM, if primitive
> doesn't checking receiver & method class compatibility.

Sounds pretty much like weak typing to me.

> A secure VM could reject implementing primitive at all, and then as a
> workaround, all you can do is temporarily compile&install given method
> in receiver's class and only then send a message.

Right and a multithreaded VM could, ... and an optimizing JIT could ...

Cheers
Philippe