[Pharo-dev] Smalltalk = strongly typed

Juan Vuletich (mail lists) juanlists at jvuletich.org
Sat Aug 3 07:15:06 EDT 2013



BTW, I especially like the idea that Smalltalk is Multityped, as an object can respond to several protocols/interfaces/type specs. So true!

Quoting "Carla F. Griggio" <carla.griggio at gmail.com>: 

> Well, I've always defined a type as the a set of values and the operations you can do with them. For example, the set of values { 1, 2, 3, 4, ... } and the operations { + , - , * , ... } would be the type Integer. With that in mind, SMALLTALK HAS TYPES: A SET OF OBJECTS AND THE MESSAGES THEY UNDERSTAND. And thanks to polymorphism a type _is not_ a synonym of a class, as instances of different objects can understand messages in common. So yes, "everything is an object" beacuse all objects are instances of a class that inherits from Object, but from my point of view it's not true that all objects are of one same type.  
>
> Everytime an object doesn't understand a message is telling you that you're doing an operation on the wrong type of object. 
>
>
> As some others have already said, I don't like the terms "strongly typed" or "weakly typed" because sometimes is ambiguous, and I rather say this: SMALLTALK HAS DYNAMIC TYPE-CHECKING IN RUNTIME (instead of compilation time), because it checks if an object can perform the operation you want (the message) in the moment of executing that operation (when you send the message). 
>
>
> Now, talking not-so-siriously, and maybe I'm getting a little code-philosofical here... If we take into account what I've just defined as a type, and knowing that all objects are instances of a class that inherits from Object, I think the term "unityped" should actually be replaced for "multityped", as the same object could respond to many different types depending on the interface its client wants it to understand. But that happens maybe in any object-oriented program, the thing is that in Smalltalk it's very natural and you don't even have to think about it (in Java you would have to explicitly use 'interfaces').
>
> On Sat, Aug 3, 2013 at 4:02 AM, Hernán Morales Durand <hernan.morales at gmail.com> wrote:
>
>
> > That is correct, there are no types in Smalltalk.
> > Cheers,
> >
> > Hernán
> >
> > El 02/08/2013 15:55, Igor Stasenko escribió: 
> >
> > > I wonder if 'types' can be applied to smalltalk at all.
> > > Saying it is 'unityped' language (since everything is an object) is
> > > same as saying it has no types.
> > >
> > > Because where you need types? When you want to manipulate with data,
> > > but in smalltalk all
> > > data manipulation semantics is provided and implemented at primitive
> > > level, but not by the language itself.
> > > At language level the only semantics which is defined is message
> > > passing, closures,
> > > return and assignment.
> > >
> > > There is no any rule(s), in smalltalk at language level, saying that
> > > result of expression:
> > >
> > > 1 + 2
> > >
> > > should be of integer type. Because this is provided by implementation
> > > but not defined by language itself e.g.:
> > > it is just a method in corresponding class, which implemented in such
> > > a way that result of expression will be instance of Integer (or
> > > SmallInteger to be precise).
> > > Now, if you change implementation so result will be float (or anything
> > > else), will such change allow you to say, that it is no longer
> > > smalltalk, or that now it is weakly typed or "anything-else typed"?
> > >
> > > Because smalltalk code do not operates directly with data, but only
> > > with references to it (which is objects).
> > >
> > > Take an assignment, for example.
> > > In staticly-typed language assignment copies the value of expression
> > > to variable, e.g.:
> > >
> > > a = 10
> > >
> > > "now variable a has value = 10"
> > >
> > > in smalltalk, assignment is not copying value, but changing the reference:
> > >
> > > a := 10
> > >
> > > "now variable a points (or refers) to object '10'"
> > >
> > > and thus, whatever 'type' used to represent the integer value 10 is
> > > completely irrelevant
> > > for assignment operation.

Cheers,
Juan Vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20130803/7392702a/attachment-0002.html>


More information about the Pharo-dev mailing list