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" <[email protected]>: 

> 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 
> <[email protected]> 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

Reply via email to