Comments for For.example

Comment on Exploring the Layout of Software Maps by akuhn

akuhn — Sat, 03 Apr 2010 17:50:27 +0000

@niko they showed a movie with like 20 snapshots from the entire version history of a system at #msa2010. As far I understood though, their visualization tool is embedded in a nightly build system. So no live stream of events as with Codemap or Codecanvas.

Comment on Exploring the Layout of Software Maps by Niko Schwarz

Niko Schwarz — Thu, 01 Apr 2010 14:33:31 +0000

I think the history-driven layout is pretty good. And c’mon, for plenty of projects the version history is right there in a cleanable repository. But their city-construction metaphor begs the question: what do you do on large merges? Those become more and more common. I have a hunch that they’re playing with data where the changes come in keystroke by keystroke, but that doesn’t need to be the way change comes to you.

Comment on Pharo Superpower: Respond to any Message by Henry

Henry — Sat, 06 Feb 2010 23:16:29 +0000

One place I’ve used it, is the BGOK package in VisualWorks, used for displaying charts.
The datasets for the graphs there are supposed to be accessed statically with accessors, but when you don’t know in from which datasets you will be displaying, telling it to access a model object which implements DNU, you can achieve just that.

Basically, if you use any external package which expects the model you provide it to follow a predefined structure, yet you need it to be dynamic, but don’t want to modify the code of the external package, DNU is your friend.
(As an alternative to light-weight classes and adding accessor methods on the go).

My #1 rule of thumb when it comes to using this superpower is: If you implement doesNotUnderstand: without calling super, you’re doing it wrong.

Comment on Pharo Superpower: Respond to any Message by akuhn

akuhn — Wed, 20 Jan 2010 00:45:19 +0000

Teachable is nice! impressive how little code is required to build a basic mock object. Guess I should include something similar in my SUnit fork, would make a nice light-weight alternative to anonymous classes.

Comment on Pharo Superpower: Respond to any Message by Torsten Bergmann

Torsten Bergmann — Tue, 19 Jan 2010 14:39:18 +0000

Take care with the DNU trick - it may be hard for others to debug if you use it in your own projects. However with the flexibility of Smalltalk you are even able to create objects and teach them step by step how to behave.

Have a look at
http://astares.blogspot.com/2005/04/teaching-behavior.html

and the code/examples in the “Teachable” project on Squeaksource

Comment on Pharo Superpower: Send Any Message by For.example » Pharo Superpower: Respond to any Message

For.example » Pharo Superpower: Respond to any Message — Tue, 19 Jan 2010 07:52:02 +0000

[...] Random notes on software, programming and languages.By Adrian Kuhn Pharo Superpower: Send Any Message [...]

Comment on Pharo Superpower: Send Any Message by akuhn

akuhn — Thu, 14 Jan 2010 13:53:45 +0000

Just read it 5 minutes ago :) you do a way better job of picking up the superheroes theme in the text, awesome. Looking forward to more superfeats!

Comment on Pharo Superpower: Send Any Message by Travis Griggs

Travis Griggs — Wed, 13 Jan 2010 22:34:15 +0000

You inspired me

Comment on Pharo Superpower: Send Any Message by Carl Gundel

Carl Gundel — Tue, 12 Jan 2010 21:14:22 +0000

Yes, of course as you ultimately get closer to the metal you dispense with dynamic code somewhere. It happens all over again when the CPU executes microcode. Down the rabbit hole we go! ;-)

Comment on Pharo Superpower: Send Any Message by akuhn

akuhn — Tue, 12 Jan 2010 19:59:53 +0000

You are right, this is the difference at the language’s core that I mentioned.

When sending messages, the sender only encodes the name of message and the receiver decided at runtime which method is to be activated. When calling method, the caller encodes at compile time the address (or at least offset) of the target method, to which it directly jumps at runtime. However, from the programmer’s view the observed behavior is (typically) the same, both cases are synchronous and thus block until the “called” method returns. I mention this because other languages (or networking systems) have true message sending where control immediately returns to the “caller” and the called method is run in parallel, ie asynchronously. So Smalltalk is kind of a hybrid in that sense. (And if you delve into the land of JIT optimization, things are put upside down anyway, and we are back at calling or even inlining methods… :)