Hi all - new to smalltalk [type services and type-safety] 
Author Message
 Hi all - new to smalltalk [type services and type-safety]



.

Quote:
> You almost have it correct. Smalltalk is considered to be a typeless
> language because of the variables, not the objects.

<knee-jerk-reaction-mode-on>

Hi Cris,

When you say "is considered to be typeless", by "whom" is it considered to
be typeless?

What you are saying is not correct. Such comments actually damage/harm the
understanding/perception of Smalltalk and thereby foster misunderstanding of
the language and its capabilities or its significance now or over the last
30 years in the continuing evolution of the field of software engineering.
As such, I feel compelled to make some comments to counter your statement.
I'm an implementer and language architect of commercial Smalltalk and have
been for more than ten years. Which, I think, fairly well puts me in an
authoritative position to comment on this subject (i.e., I would be one of
the "whom" group members).

Smalltalk is a "pure" OO language which in and of itself implies a
requirement for [some kind of] a type system [which is a characteristic that
scheme and most scripting languages lack -- although most have recognized
the need for such facilities and provided partial/or-inconsistent/ad-hoc OO
extensions].

Smalltalk is considered by most/all to be the embodiment [and by some the
progenitor of the concept] of a [pure] OO language. What distinguishes
Smalltalk from most other "OO" languages is that everything is treated
uniformly as an object, and the type system itself provides a uniform single
<any/Object> type root [ANSI 98 standard makes the root <any/nil>, which was
classic ST-80 implemented as <Object>] Thus allowing Smalltalk to avoid many
of the genericity problems/issues challenging statically typed languages and
their declarative facilities.

As with most "typed" languages, there are a number of issues [semantic
concerns] as to what a "type" represents; w.r.t. implementation usage versus
pure type-equations/transforms and corresponding application of set-theory.
The important concern, in Smalltalk, for type verification is that of
contractual semantics. Or put another way, the verification of correct
method/behavi{*filter*}usage, where such verification is not limited to
validation of type equations relating to in/out function
parameters/expressions.

While [optional or mandatory] declarative type systems [for Smalltalk or
other languages] allow static type usage verification (static type safety),
that is insufficient to ensure "correct" program behavior [i.e., hence the
danger/flaw in succumbing to the implications of the use of the word "safe"
in statically type checked systems].

It is certainly arguable that the need for 100% static verification of type
usage is, in large part, to support static language implementation
techniques [and as such does not necessarily enhance design reuse or aid in
improving algorithmic/design correctness]. A sarcastic/cynical [tongue in
cheek] view would be to say that static type theory evolved in the [and was
peer-pressure/constrained by] early years to support/enhance the credibility
of computers and software work as a "science" and to offer a solution to the
pressures of ever increasing numbers of PhD candidates needing an open-ended
field based on mathematical principles to ensure sufficient thesis topics.
Mathematicians and others found "hacking/programming" to be fun and
interesting but they needed it to become a credible field/discipline of
"science" -- which I've always felt was better characterized as
"engineering" ;-)

I also suggest that a "large" part of the need for [and/or actual
application of] static type verification in "purely" static languages is
purely to support the implementation techniques typically used to build
them. They typically either have no facilities for dynamic type verification
or their facilities are very inefficient compared to their "preferred"
implementation mechanics of using "typeless" runtime structures. Where the
implementation use of "typeless/non-reflective" runtime structures are the
"large" part of what mandates the fear/requirement/need for 100%
verification of static "structural-representation" type verification. And
that, is largely driven by the evolution of procedural programming
techniques and facilities that promoted/fostered structural/data
optimization/coding mechanisms that discouraged encapsulation and
abstraction.

In Smalltalk a <Protocol>, class/<Behavior>, or <Interface> is both a first
class declarative/static entity and a first class runtime represention of an
arbitrary [human defined/agreed-upon] set of collaboration assumptions and
additional pre/post condition rules and side-effect semantics [which, for
the very reasons correctness can't be proved, are only heuristically
validatable through dynamic verification (including unit testing -- which
was invented in Smalltalk)].

Various dialects of Smalltalk (and/or framework facilities) allow you to
declare the type of a variable to be something other than <Object>. There
have been a number of tools available over the years to allow not only
static type analysis, but also declaration/management of contractual
semantics, and dynamic runtime analysis and assisted refactoring.

The definition of "strongly typed" is "a programming language which performs
type checking and thus ensures that type errors do not lead to erroneous
computations" [ref papers from Milner 1978 and Strachey 1967]. Smalltalk
always guarantees this since its entire execution/dispatch architecture is
based on reflective use of type information for method invocation/binding.
This is why it is a "dynamically type safe" language, and it is why type
information and type system services [including multi-methods/overloading]
are optional.

As to other "whom" group members, most of the "published" academic
literature relating to Smalltalk refers to it as being a "dynamically typed
language" (not a typeless language).

However you look at it, Smalltalk is "strongly typed" and it is incorrect to
characterize it as typeless.

To make any statement or mischaracterization as to it being "unsafe" or
"typeless" does a great disservice to the language. It is unfortunate/bogus
that static languages have (over the years) subsumed ownership/definition of
the notions of type and type-safety [thereby implying that languages which
do not offer the same static analysis mechanisms are unsafe or typeless].
The various uses of the phrases "safe", "type-safe", "type-safety", etc are
dangerous/misleading as they easily allow one to be lulled into thinking
that statically verified "type" equations for some "typically broken"
type-system imply a degree of "safety" about program behavior which typical
programmers mis-translate into having/implying some confidence/assurance of
contractual/semantic correctness.

Were you trying to suggest that it is "typeless" because variables are, in
classic (vanilla) Smalltalk, typed as containers of <Object> or <any>? If
so, that does not make Smalltalk typeless. Arguably, for those
implementations which are used without any declarative type facilities,
those implementations could be interpreted as treating "variables" as being
typeless. The distinction between "variables" as opposed to "objects" is a
"static" view [variables are a declarative (static) construct, whereas
objects are a runtime/dynamic construct].

The ability to declaratively associate contractual type information with
variables and expressions is clearly valuable, but unfortunately this is
only a quite limited aspect of what is typically imposed/implied in manifest
"static type" systems.

As for declarative type systems in Smalltalk, there are a number of
examples. My work on designing QKS Smalltalk (and SmallScript) provides
optional [declarative/static&dynamic] type services. The Smalltalk optional
static type system facility called StrongTalk [see OOPLSA 93 proceedings]
that happened to be part of the Animorphic HotSpot technology (later
acquired by Sun for use in Java) has been around for a very long time and
provided genericity facilities still lacking in languages like Java and C++.
Woody, developed in the late 80's to mid 90's [at KSC -- knowledge systems
corp] included a multi-dialect type system for Smalltalk.

</knee-jerk-reaction-mode-on>

--
-- Dave S. [ http://www.*-*-*.com/ ]
   Smalltalk for the AOS Platform and The Microsoft.NET Framework

Quote:
> In the same way
> that Java/C++ are strongly typed, because of the variables. Scheme
> also has strongly typed data (strangely called objects), but is
> considered to be typeless because of the nature of its variables.

> **********************************************************************
> Cris A. Fugate          Lucent Technologies, Robust Process Automation

> 630 713-8255            Sponsor of the lucent.lang.tcl newsgroup


> > > Technically neither is Scheme, but variable types are not declared
> > > and can hold anything.

> > > Therefore, Smalltalk is typeless.

> > This is not correct.

> > Smalltalk provides a dynamic type system that is uniformly and
reflectively
> > typed. It is classified as a strongly typed language, but it is not a
> > "statically" typed language.

> > Variables, as containers of type <any>, and thus able to hold all types,
are
> > one of the features that enables classic Smalltalk to circumvent the
classic
> > problems/limitations of Java and C++ with regard to parameterized types
and
> > primitive/value types.

> > --
> > -- Dave S. [ http://www.*-*-*.com/ ]
> >    Smalltalk for the AOS Platform and The Microsoft.NET Framework



Sun, 25 Jan 2004 01:40:32 GMT  
 Hi all - new to smalltalk [type services and type-safety]
What you say about objects is true. But I am not talking about that!!!
I am saying that Smalltalk is typeless due to the nature of variables.
No, it is not incorrect to call it typeless for that reason because
it is the truth and I have seen a thousand references to Smalltalk being
typeless for this very reason. Nor do I believe this statement is
damaging or that it is an injustice to call it that because to some people
it is a very important feature! To me the use of objects in Smalltalk
are secondary to the fact that the variables are typeless. If I
thought otherwise I would go use Java (which is probably why most people
dont use Smalltalk). But I am tired of talking at the wall so I will
end this fruitless discussion.

**********************************************************************
Cris A. Fugate          Lucent Technologies, Robust Process Automation

630 713-8255            Sponsor of the lucent.lang.tcl newsgroup

Quote:

> Hi Cris,

> What you are saying is not correct. Such comments actually damage/harm the
> understanding/perception of Smalltalk and thereby foster misunderstanding of
> the language and its capabilities or its significance now or over the last
> 30 years in the continuing evolution of the field of software
engineering..

cut

> Were you trying to suggest that it is "typeless" because variables are, in
> classic (vanilla) Smalltalk, typed as containers of <Object> or <any>? If
> so, that does not make Smalltalk typeless.. The distinction between
> "variables" as opposed to "objects" is a "static" view [variables are a
> declarative (static) construct, whereas objects are a runtime/dynamic
> construct].

cut

> </knee-jerk-reaction-mode-on>

> --
> -- Dave S. [ http://smallscript.net ]
>    Smalltalk for the AOS Platform and The Microsoft.NET Framework



Sun, 25 Jan 2004 03:09:38 GMT  
 Hi all - new to smalltalk [type services and type-safety]
Something like this should probably go into an FAQ as it ignites emotions
every year or so.

A pretty common strict terminology is to consider two orthogonal axes:
static vs dynamic typing and strong vs weak typing.  The former is about
variables -- static typing is with types verified by the compiler according
to explicit declaration, dynamic is what you call "typeless".  The latter is
about objects.  Weak is when an object can be interpreted any way you want,
like C where you can cast things all you want.  Strong is like Smalltalk
where an object has a specific type associated with it that in general
cannot be arbitrarily changed.  A language is really described by a *pair*
of such orthogonal properties: Smalltalk has dynamic strong typing, while C
has static weak typing.

As opposed to an organized scheme like this, sloppy terms like "typeless"
can be understood by people differently.  There is hardly a point to get
upset or argue about them, or about whether variables are more important
than objects or not.

--

VisualWorks Engineering



.

Quote:
> What you say about objects is true. But I am not talking about that!!!
> I am saying that Smalltalk is typeless due to the nature of variables.
> No, it is not incorrect to call it typeless for that reason because
> it is the truth and I have seen a thousand references to Smalltalk being
> typeless for this very reason. Nor do I believe this statement is
> damaging or that it is an injustice to call it that because to some people
> it is a very important feature! To me the use of objects in Smalltalk
> are secondary to the fact that the variables are typeless. If I
> thought otherwise I would go use Java (which is probably why most people
> dont use Smalltalk). But I am tired of talking at the wall so I will
> end this fruitless discussion.

> **********************************************************************
> Cris A. Fugate          Lucent Technologies, Robust Process Automation

> 630 713-8255            Sponsor of the lucent.lang.tcl newsgroup


> > Hi Cris,

> > What you are saying is not correct. Such comments actually damage/harm
the
> > understanding/perception of Smalltalk and thereby foster
misunderstanding of
> > the language and its capabilities or its significance now or over the
last
> > 30 years in the continuing evolution of the field of software
> engineering..

> cut

> > Were you trying to suggest that it is "typeless" because variables are,
in
> > classic (vanilla) Smalltalk, typed as containers of <Object> or <any>?
If
> > so, that does not make Smalltalk typeless.. The distinction between
> > "variables" as opposed to "objects" is a "static" view [variables are a
> > declarative (static) construct, whereas objects are a runtime/dynamic
> > construct].

> cut

> > </knee-jerk-reaction-mode-on>

> > --
> > -- Dave S. [ http://smallscript.net ]
> >    Smalltalk for the AOS Platform and The Microsoft.NET Framework



Sun, 25 Jan 2004 03:40:19 GMT  
 Hi all - new to smalltalk [type services and type-safety]

Quote:

> What you say about objects is true. But I am not talking about that!!!
> I am saying that Smalltalk is typeless due to the nature of variables.
> No, it is not incorrect to call it typeless for that reason because
> it is the truth and I have seen a thousand references to Smalltalk being
> typeless for this very reason. Nor do I believe this statement is

No, you are not quite getting it.  Smalltalk is not <manifestly> typed.
It is in fact <dynamically> typed.  Were it typeless (i.e., an absence
of types), any object could attempt to execute any message (as in, say,
C++).

Quote:
> damaging or that it is an injustice to call it that because to some people
> it is a very important feature! To me the use of objects in Smalltalk
> are secondary to the fact that the variables are typeless. If I
> thought otherwise I would go use Java (which is probably why most people
> dont use Smalltalk). But I am tired of talking at the wall so I will
> end this fruitless discussion.

It's semantics, but an important bit of semantics.  All objects in
Smalltalk have a type; they just aren't statically checked at compile
time.  rather, they are dynamically checked at runtime.

Quote:

> **********************************************************************
> Cris A. Fugate          Lucent Technologies, Robust Process Automation

> 630 713-8255            Sponsor of the lucent.lang.tcl newsgroup


> > Hi Cris,

> > What you are saying is not correct. Such comments actually damage/harm the
> > understanding/perception of Smalltalk and thereby foster misunderstanding of
> > the language and its capabilities or its significance now or over the last
> > 30 years in the continuing evolution of the field of software
> engineering..

> cut

> > Were you trying to suggest that it is "typeless" because variables are, in
> > classic (vanilla) Smalltalk, typed as containers of <Object> or <any>? If
> > so, that does not make Smalltalk typeless.. The distinction between
> > "variables" as opposed to "objects" is a "static" view [variables are a
> > declarative (static) construct, whereas objects are a runtime/dynamic
> > construct].

> cut

> > </knee-jerk-reaction-mode-on>

> > --
> > -- Dave S. [ http://smallscript.net ]
> >    Smalltalk for the AOS Platform and The Microsoft.NET Framework

--
James A. Robertson
Product Manager (Smalltalk), Cincom

<Talk Small and Carry a Big Class Library>


Sun, 25 Jan 2004 07:53:03 GMT  
 Hi all - new to smalltalk [type services and type-safety]

Quote:

> A pretty common strict terminology is to consider two orthogonal axes:
> static vs dynamic typing and strong vs weak typing.

I can see (at least) a third dimension:  What is the main purpose of the
type-system.  Is it  for the benefit of the human reader, or for the benefit of
the compiler ? In Smalltalk the names of arguments can indicate the type the
programmer wants you to to pass to it.  Typically everything works fine in
practice in Smalltalk, because *programmers* know the type expected of
arguments.

I would say: Trust the programmers more to make the program correct, than the
compiler.

The above is true as long as we can provide programmers with adequate tools to
communicate the interface contracts of their methods and classes to each other
(as well as to their future selves). This  is easily facilitated by  Smalltalk's
readable keyword syntax, which allows you to specify both the purpose/role of
the argument (with the keyword) as well as its expected type (with the argument
name).

Smalltalk's development paradigm can be characterized by "Programmer as the
reader". Since there are so many reusable components, what really matter is that
you can easily read/understand how and where to use them.

-Panu



Sat, 24 Jan 2004 08:13:51 GMT  
 Hi all - new to smalltalk [type services and type-safety]

:> damaging or that it is an injustice to call it that because to some people
:> it is a very important feature! To me the use of objects in Smalltalk
:> are secondary to the fact that the variables are typeless. If I
:> thought otherwise I would go use Java (which is probably why most people
:> dont use Smalltalk). But I am tired of talking at the wall so I will
:> end this fruitless discussion.
:
:It's semantics, but an important bit of semantics.  All objects in
:Smalltalk have a type; they just aren't statically checked at compile
:time.  rather, they are dynamically checked at runtime.

But it is still true that the Smalltalk variables are typeless.
Variables are something that exist in human readable source code and
are not the same thing as objects.

--
*        Matthew B. Kennel/Institute for Nonlinear Science, UCSD          
*
*      "To chill, or to pop a cap in my dome, whoomp! there it is."
*                 Hamlet, Fresh Prince of Denmark.



Sun, 25 Jan 2004 09:22:29 GMT  
 Hi all - new to smalltalk [type services and type-safety]

Quote:


>> What you say about objects is true. But I am not talking about that!!!
>> I am saying that Smalltalk is typeless due to the nature of variables.
>> No, it is not incorrect to call it typeless for that reason because
>> it is the truth and I have seen a thousand references to Smalltalk being
>> typeless for this very reason. Nor do I believe this statement is

> No, you are not quite getting it.  Smalltalk is not <manifestly> typed.
> It is in fact <dynamically> typed.  Were it typeless (i.e., an absence
> of types), any object could attempt to execute any message (as in, say,
> C++).

I don't know smalltalk, could you please answer a quick question so that I
too could understand smalltalks type system.

Is there anyway to enforce that the following code would be illegal (other
than enforcing it yourself)

unsigned_integer i = container1.size() + container2.size();
unsigned_integer i = container1.size() - container2.size()

Clearly, the first line is legal, and the second should be rejected by any
strong type system (in c++ the legacy type system does not reject this, but
the class static type system can, just as you would expect).  (please
consider the idea that unsigned integer is a derived class and a sub type
of integer, I understand that smalltalk does not always require subtyping,
but in this case atleast, it is correct).  I'm actually doing some research
on type systems (and the set theory underlying them), and it would be
interesting to see a different approach to this problem

Thanks
Brad

Thanks
Brad



Sun, 25 Jan 2004 09:44:13 GMT  
 Hi all - new to smalltalk [type services and type-safety]

Quote:

> But it is still true that the Smalltalk variables are typeless.
> Variables are something that exist in human readable source code and
> are not the same thing as objects.

I don't understand what you mean by "exist in human readable source code".

What are you getting at here? That:

(1) the placeholder for the thing is not the same thing as the thing, i.e.,
the
value vs. variable issue in the relational world? See Date :-)

or:

(2) That a Smalltalk variable (which means the attribute of an object and
not what that attribute contains) can contain "anything" and hence is
typeless?

If (1), then why bring this up in a discussion about types? Its an
orthogonal subject.
If (2), then not so. A Smalltalk attribute contains an object. That is
typed.
Its the "anything" type.

Its been said before that Smalltalk has types. One type called Object. (*)
This type declares an object that can be sent any message. Either the
message
matches a defined method (which then evaluates the method) or it doesn't
(which then evaluates the does-not-understand method). That's it.

(*) Note to non-Smalltalkers: Its possible to create classes (and their
instances)
 that do *not* inherit from Object, but that is for special cases like
Proxies.
These are still objects; they just don't inherit from Object. Not an
important
subject in this discussion.



Sun, 25 Jan 2004 10:14:31 GMT  
 Hi all - new to smalltalk [type services and type-safety]
in smalltalk there is nothing wrong with 2nd expression since Smalltalk is
** dynamically ** typed :

In Smalltalk you would write:
   positive_integer_i  := container1 size - container2 size.

here the variable name is ** misleading ** because it could evaluate to a
negative integer.

if negative integer is an error condition on would write :

    ( positive_integer_i := container1 size - container2 size ) < 0 ifTrue:
[ NegativeResultError signal: unsigned_integer i ].

if you expect this check more often you can define a method errorIfNegative
in Number:

    Number>>errorIfNegative
    self < 0 ifTrue: [ NegativeResultError signal: self].

and rewrite your expression as
    ( positive_integer_i := container1 size - container2 size )
errorIfNegative.

So in ** statically ** typed languages - the type information in the program
is used the check the types at compile time to be able to ** throw it away
** at runtime. Unfortunatley some time you need this information and so the
Java world must introduce a separate concept of reflection -which in this
form is
in the Smalltalk world unnecessary because this reflective information is
carried with the object.

Frank



Sun, 25 Jan 2004 10:23:59 GMT  
 Hi all - new to smalltalk [type services and type-safety]
assorted thoughts on smalltalk typing.


Quote:
>What you say about objects is true. But I am not talking about that!!!
>I am saying that Smalltalk is typeless due to the nature of variables.
>No, it is not incorrect to call it typeless for that reason because
>it is the truth and I have seen a thousand references to Smalltalk being
>typeless for this very reason.

First of all I understand this viewpoint. Coming from other languages, one
thing that is very is distinctive in Smalltalk is that typing information does
not have to be added to variable declarations. IMHO it makes sense to use the
word typeless in the specific sense that *variable declarations* (as opposed
to Smalltalk itself) are typeless. I dont think this is in conflict with the
counterpoints made by David Simmons and others.

--

I think a simple way to distinguish typing in Smalltalk from other languages
is to think about which code in the system is aware of types. In Smalltalk the
awareness of types is moved from the compiler, into the runtime system - ie
the vm, and the objects themselves.

Arguably it is really static languages which are typeless, to the extent that
their runtime system is not aware of types.

--

I vaguely recall a comment made a *long* time ago by John Clapperton which
turned a light on for me in understanding Smalltalk - it was something to the
effect that objects dont have names. A corrallary being that one object could
be known by many names (ie variables). Steeped in Smalltalk (or Java) this
seems perfectly natural but in my experience that is an aha to a newbie coming
from other languages where values are tightly coupled with variables.

A related idea was something else i read (was it Coplien?)  that variables in
Smalltalk are just labels that you could peel off of objects and slap on other
objects. In any case, in static languages and even in Smalltalk, there is no
notion of variables at runtime, they've been stripped away and replaced by
memory location references. Variables are just conveniences to the programmer
for thinking about memory locations, a fiction. OTOH a language like Lisp is
interesting in the regard that knowledge of variables  is carried all the way
into the runtime system, ie variables themselves are 'first class'.

-ar



Sun, 25 Jan 2004 14:12:39 GMT  
 Hi all - new to smalltalk [type services and type-safety]

Quote:

>> What you say about objects is true. But I am not talking about that!!!
>> I am saying that Smalltalk is typeless due to the nature of variables.
>> No, it is not incorrect to call it typeless for that reason because
>> it is the truth and I have seen a thousand references to Smalltalk being
>> typeless for this very reason. Nor do I believe this statement is

>No, you are not quite getting it.  Smalltalk is not <manifestly> typed.
>It is in fact <dynamically> typed.  Were it typeless (i.e., an absence
>of types), any object could attempt to execute any message (as in, say,
>C++).

But isn't this exactly what happens?  You *can* send any message to any
object, and an attempt to execute the message is actually made.  Indeed,
by implementing #doesNotUnderstand: you can make any object able to
execute any message (in some sense).

Quote:

>> damaging or that it is an injustice to call it that because to some people
>> it is a very important feature! To me the use of objects in Smalltalk
>> are secondary to the fact that the variables are typeless. If I
>> thought otherwise I would go use Java (which is probably why most people
>> dont use Smalltalk). But I am tired of talking at the wall so I will
>> end this fruitless discussion.

>It's semantics, but an important bit of semantics.  All objects in
>Smalltalk have a type; they just aren't statically checked at compile
>time.  rather, they are dynamically checked at runtime.

When?  All that is checked is whether a particular object can understand
a particular message.  That's not exactly 'type' checking.  Its more like
a sort of 'interface' checking.

Steve Zara



Sun, 25 Jan 2004 16:51:17 GMT  
 Hi all - new to smalltalk [type services and type-safety]

Quote:



> >> What you say about objects is true. But I am not talking about that!!!
> >> I am saying that Smalltalk is typeless due to the nature of variables.
> >> No, it is not incorrect to call it typeless for that reason because
> >> it is the truth and I have seen a thousand references to Smalltalk being
> >> typeless for this very reason. Nor do I believe this statement is

> >No, you are not quite getting it.  Smalltalk is not <manifestly> typed.
> >It is in fact <dynamically> typed.  Were it typeless (i.e., an absence
> >of types), any object could attempt to execute any message (as in, say,
> >C++).

> But isn't this exactly what happens?  You *can* send any message to any
> object, and an attempt to execute the message is actually made.  Indeed,
> by implementing #doesNotUnderstand: you can make any object able to
> execute any message (in some sense).

In C or C++, actual execution is attempted, with disasterous attempts.

Quote:

> >> damaging or that it is an injustice to call it that because to some people
> >> it is a very important feature! To me the use of objects in Smalltalk
> >> are secondary to the fact that the variables are typeless. If I
> >> thought otherwise I would go use Java (which is probably why most people
> >> dont use Smalltalk). But I am tired of talking at the wall so I will
> >> end this fruitless discussion.

> >It's semantics, but an important bit of semantics.  All objects in
> >Smalltalk have a type; they just aren't statically checked at compile
> >time.  rather, they are dynamically checked at runtime.

> When?  All that is checked is whether a particular object can understand
> a particular message.  That's not exactly 'type' checking.  Its more like
> a sort of 'interface' checking.

What's checked is whether an object responds to the message in question.

Quote:

> Steve Zara

--
James A. Robertson
Product Manager (Smalltalk), Cincom

<Talk Small and Carry a Big Class Library>


Sun, 25 Jan 2004 20:00:38 GMT  
 Hi all - new to smalltalk [type services and type-safety]
Brad,

The way I would solve this problem is to create a new class that would
enforce the positive integer contraint (i.e. if it ever we're to be made
negative, you signal an exception).

But, this does not solve the type inferencing problem that you presented by
preventing the compilation of the code in the first place.  However, the
runtime solution using a new class to enforce the constraint is much more
practical in terms of building real world, enormously complex systems.

- Stephen


Quote:

> > I don't know smalltalk, could you please answer a quick question so that
I
> > too could understand smalltalks type system.

> > Is there anyway to enforce that the following code would be illegal
(other
> > than enforcing it yourself)

> > unsigned_integer i = container1.size() + container2.size();
> > unsigned_integer i = container1.size() - container2.size()

> This may have too much c flavor, let me try to make a clearer example (I
> don't expect the syntax of smalltalk to be the same, just the semantics)

> positive_integer i := container1.size();

> i +=: container2.size();  //legal

> negative_integer j := -7;
> i -=: j; //legal

> postive_integer k := container2.size();
> i -=: k; //illegal the possible value of i - k may not be positive

> Suppose the case where integer is the base class of positive_integer and
> negative_integer, and the case where there is no common base (other than
> the root base, object I belive).  I'm guessing in the former case, i is
now
> bound to an integer.  Fair enough.  In the later case, the program should
> be rejected.

> Thanks
> Brad



Sun, 25 Jan 2004 22:23:24 GMT  
 Hi all - new to smalltalk [type services and type-safety]

Quote:



>> >> What you say about objects is true. But I am not talking about that!!!
>> >> I am saying that Smalltalk is typeless due to the nature of variables.
>> >> No, it is not incorrect to call it typeless for that reason because
>> >> it is the truth and I have seen a thousand references to Smalltalk being
>> >> typeless for this very reason. Nor do I believe this statement is

>> >No, you are not quite getting it.  Smalltalk is not <manifestly> typed.
>> >It is in fact <dynamically> typed.  Were it typeless (i.e., an absence
>> >of types), any object could attempt to execute any message (as in, say,
>> >C++).

>> But isn't this exactly what happens?  You *can* send any message to any
>> object, and an attempt to execute the message is actually made.  Indeed,
>> by implementing #doesNotUnderstand: you can make any object able to
>> execute any message (in some sense).

>In C or C++, actual execution is attempted, with disasterous attempts.

I would not disagree with that!  But I don't think this distracts
from my point.

- Show quoted text -

Quote:

>> >> damaging or that it is an injustice to call it that because to some people
>> >> it is a very important feature! To me the use of objects in Smalltalk
>> >> are secondary to the fact that the variables are typeless. If I
>> >> thought otherwise I would go use Java (which is probably why most people
>> >> dont use Smalltalk). But I am tired of talking at the wall so I will
>> >> end this fruitless discussion.

>> >It's semantics, but an important bit of semantics.  All objects in
>> >Smalltalk have a type; they just aren't statically checked at compile
>> >time.  rather, they are dynamically checked at runtime.

>> When?  All that is checked is whether a particular object can understand
>> a particular message.  That's not exactly 'type' checking.  Its more like
>> a sort of 'interface' checking.

>What's checked is whether an object responds to the message in question.

Yes, that is what I said.  However, its not 'type checking' - there is
no #isKindOf: test.

- Show quoted text -

Quote:

>> Steve Zara

>--
>James A. Robertson
>Product Manager (Smalltalk), Cincom

><Talk Small and Carry a Big Class Library>



Mon, 26 Jan 2004 02:49:37 GMT  
 Hi all - new to smalltalk [type services and type-safety]

Quote:

>  But it is still true that the Smalltalk variables are typeless. Variables are
> something that exist in human readable source code and are not the same thing as
> objects.

This is definitely true and a good point. In Smalltalk objects have types, but any
variable can contain any type of object.

Think of a variable as a box. In Smalltalk you can create boxes and put any type
of object into any box you want. In Java/C++ when you create a 'box' you must also
declare that only specific types objects can be put into it.

I prefer a box that allows me to put anything inside it,  over a box that
constrains its contents to only certain types of objects.

Static typing (of variables) is like saying: I expect to place only one type of
objects into this box. Therefore I make it impossible to put any other type of
object  in it. This helps me in knowing what types of objects are inside the box
without having to look inside it.

-Panu



Mon, 26 Jan 2004 18:35:12 GMT  
 
 [ 58 post ]  Go to page: [1] [2] [3] [4]

 Relevant Pages 

1. Type restrictions / type safety in Smalltalk?

2. Python 2.2, creating new types from base types

3. New User Question: extension types and python 2.2/class/type

4. Smalltalk type annotation or type inference engine ?

5. Eiffel Type-Safety Reference

6. breaking Eiffel's type safety?

7. Language Design (Re: Dylan type-safety )

8. Dylan type-safety

9. Realising type-safety

10. Realising type-safety

11. Eiffel type safety.

12. type safety in LISP

 

 
Powered by phpBB® Forum Software