Smalltalk, but not quite

A dozen years ago, smalltalk was considered the number one graphical interface language, pretty much defining what is nowadays known as turtle graphics.

Unfortunately, smalltalk has a very old object system, one that is considered ancient today; So I decided to whip out a design for a less verbose object system, one that may be easier to learn.

What do you think?


import System.
import Extra/Qt [QtGui].

class Example uses (QtGui/QWidget) [
    new := [
        super: new.
        self initUI.
    ]

    initUI := [
        self setGeometry: [300, 300, 250, 150].
        self setWindowTitle: "Icon".
        self setWindowIcon: (QtGui/QIcon new: "web.png").
        self show.
    ]
].


define [app, ex]
app := QtGui/QApplication new: System/ARGV.
ex := Example new.
System/Exit: (app: exec).

I'm not really familiar with Smalltalk. It looks like both arrays(?) and lambdas(?) can be used as rvalues. How does the parser make the distinction without exponential lookahead blowup?

How does the old object model differ from the new one? What exactly are your improvements? I can't tell what you're trying to do.

>>2
How does the parser make the distinction without exponential lookahead blowup?

It doesn't have to. In smalltalk, everything is an object, that goes for blocks as well (a '[ ... ]' construct is a block). In this case, it's a block of values. A function is also just a block.

How does the old object model differ from the new one? What exactly are your improvements? I can't tell what you're trying to do.

It's all about syntax here, really.

turtle graphics
U MENA ROGO

>>3
I don't know stuff about Smalltalk. Assume I know nothing and detail your improvements accordingly.

Smalltalk has generally been superseded by D. Learn D.

Those points in the end of statements are directly from COBOL, amirite?

>>7
Nope, smalltalk.

I don't know if stuff like QtGui/QIcon would work out if you were going to support the symbolic arithmetic operators. What if QtGui and QIcon where both floating point numbers in this case? But maybe it could work. I suppose the / would be a method implemented in QtGui (whatever it might be), and in this case, it would take one unevaluated name argument QIcon and retrieve the QIcon inner type of QtGui?

i don't really like the class inheritance part where you have a "new" function that has to be sure to call "super new"

check 'em

>>11 at 11:11

get on my level

Smalldubs

>>9
QtGui in this case, would be an uninitiated class object, not a class instance. So, operator overloading wouldn't apply. Besides, the '/' syntax is just module namespacing eyecandy.

>>10
Could be done better... frankly, I never attempted to read into smalltalks Object system, because it's very frustrating.

Back then, these overly verbose "AuthorName", "AuthorEmail", etc, attributes may have seemed like a good idea, but nowadays, they are close to pointless.

>>1
props to op for posting some smalltalk code, which is something you almost never see (unless you are a part of their insular community)

I like it

using Smalltalk
born after 1979
ISHYGGDT

Just switch to Ruby already and stop trying to teach an old language new concepts.

>>16
Smalltalk is a consistent language with a nice object system. Ruby is shit.