Typed Systems, Type Inference, etc
Diego Gomez Deck
DiegoGomezDeck at ConsultAr.com
Sun Jul 21 11:05:58 UTC 2002
Hi David,
>Just for consideration, here is what the actual point behavior
>declaration looks like in SmallScript (abridged information, various
>methods elided).
Thanks for your really helpful email, I'll give you my point of view.
>Class name: PointObject
> fields: virtual property x,y;
>{
> "" Constructor(s)
> Function [<::(<>,<>)>
> x: x y: y
> ^new() x: x; y: y
> ].
>
> "" Instance method(s)
> Method [<'cloning'>
> + v
> ^class()(x + v, y + v)
> ]
> Method [<'cloning'>
> + <PointObject> pt
> ^class()(x + pt.x, y + pt.y)
> ]
>}
>
>Where the alternate #::(<>,<>) class-method name, allows writing code as
>follows:
>
>Eval [
> "" SmallScript form
> |x := 10, y := 12|
> stdout cr << Point32(x,y).
>]
>
>Eval [
> "classic form"
> |x y| x := 10. y := 12.
> Transcript cr; nextPutAll: (Point32 x: x y: y).
>]
>
>Both of the above, will compile and behave correctly in SmallScript --
>the use of <Transcript> instead of <stdout> requires a reference to the
>"ANSI" library (module).
>
><PointObject> happens to be defined as a base-class (which is indicated
>by the suffix "...Object"). We could just as easily have defined it as a
>mixin with the same virtual field declarations.
>==============
>Translating the PointObject declarations to a more "classic Smalltalk"
>format would read as:
>
>Class name: PointObject
> fields: virtual property x,y;
>{
> "" Constructor(s)
> Function ["removed the alternate method name"
> x: x y: y
> "explicitly reference <self> in #new"
> ^(self new) x: x; y: y
> ].
>
> "" Instance method(s)
> Method ["removed the 'cloning' category-tag annotation"
> + v
> ^(self class new)
> x: (x + v) y: (y + v)
> ]
> Method [
> + <PointObject> pt
> ^(self class new)
> x: (x + pt.x) y: (y + pt.y)
> ]
>}
>
>NOTE: Both forms shown here (original form, classic Smalltalk form) will
>compile and produce the exact same code and behavior. With the noted
>comments where I removed some extra annotations and replaced them with
>comments.
In ST you can write code like that:
Point>>+ anObject
^ anObject addToPoint: self.
Point>>addToPoint: aPoint
^ (self x + aPoint x) @ (self y + aPoint y)
Number>>addToPoint: aPoint
^ (self + aPoint x) @ (self + aPoint y)
String>>addToPoint: aPoint
^ (self asNumber + aPoint x) @ (self asNumber + aPoint y)
My point is: The gain don't pay the complexity added to the language.
>Given the above definitions, we can then create a variety of point
>classes.
>
>Class name: Point extends: PointObject
> fields: auto x,y.
>Class name: Point32 extends: PointObject
> fields: auto struct int32 x,y.
>Class name: Point16 extends: PointObject
> fields: auto struct int16 x,y.
>Class name: PointFloat32 extends: PointObject
> fields: auto struct Float32 x,y.
>Class name: PointFloat64 extends: PointObject
> fields: auto struct Float64 x,y.
>===============
>
>The significant point here is that we do not need to write *any* methods
>for these various <PointObject> subclasses. They inherit all the
>necessary behavior from the base class
That's true, because you move the complexity to the "fields" part of the
declaration.
I think that the language must be small as possible and let's the objects
to create the idioms to talk to them.
[snip]
>Hopefully, this provides some additional food for thought.
Yes... of course, thanks for it! We ever learn from these type of
discussions.
>Introducing
>"types" into Smalltalk should be done with care and consideration. It
>offers significant opportunity to enhance Smalltalk -- but there are
>also classic static-typing concepts that may (depending on design goals)
>be undesirable if the objective is to enrich Smalltalk for dynamic
>typing behavior.
>
>-- Dave S. [SmallScript Corp]
>
>SmallScript for the AOS & .NET Platforms
>David.Simmons at SmallScript.com | http://www.smallscript.org
Cheers,
Diego Gomez Deck
More information about the Squeak-dev
mailing list
|