Pool Constants or Class Messages?

I'm just wondering about the accepted Smalltalk form here..

Smalltalk provides us the pool constants that code can use, but I'm
wondering if I should even bother...

with:
Win32Error signal: FILE_NOT_FOUND

does the compiler insert the constant value into the bytecode? (Whatever the
FILE_NOT_FOUND constant is defined to?)

Would it be better/worse to instead write:

Win32Error signal: Win32Error fileNotFound

I understand that this inccurs the extra overhead of an additional message
send (all of a few nanoseconds or whatever), so you could also write it like
so:

Win32Error signal: ##(Win32Error fileNotFound)

yes?

I'm just wondering what people's preferences/suggestions are. Personally I
like the class messages, combined with the Dolphin compiler inlining ##()

Looking at the disassembled byte code:

Here is code/bytecode using pool constant:

generatePool
  | value |
  value := NOTFOUND.
  ^value

1 Push 1
2 Store Temp[0]
4 Return

Here is code using dolphin ##() constant:

generateClassInline
  | value |
  value := ##(BasicObject notFound).
  ^value

1 Push 1
2 Store Temp[0]
4 Return

And here is a class message send:

generateClassMessage
  | value |
  value := self class notFound.
  ^value

1 Push self
2 Special Send #class
3 Send[1]: #notFound with 0 args
4 Store Temp[0]
6 Return

Arguments for pool constants: They're faster
Arguments against pool constants: They're harder to manage

Arguments for inlined messages: They're faster
Arguments against inlined messages: Changing the message value doesn't
update references. You also need to couple the code to a particular class at
compile time. Also, would the image stripper strip the inlined messages?

Arguments for message sends: Overridable
Arguments against: message send overhead (negligable) vs other two options.

Have I missed anything major? This is just to satisfy my curiosity.

Sean,

> Have I missed anything major? This is just to satisfy my curiosity.

Another method that can be used, and is used in Dolphin (see the "masks"
in the View class), is to use ClassVariable constants.  They can be
useful in some occasions, less "messing about" than pools and less
"clutter" than methods but values only accessible within the class and
it's subclasses.

Which technique to use?  I would say that each of them has it's own
little niche (for example, you wouldn't want to define Windows api
constants using methods) and the appropriate one is usually pretty obvious.

In your example I would have thought including the Win32Errors pool and
using ERROR_FILE_NOT_FOUND would be preferable.  It's easy to do and
fits in with the rest of the image.

On the other point, I don't think there's much advantage in using a
compiler inlining in the way you suggest.  The gain over a simple
accessor message send is pretty minimal and it could complicate things -
what happens if you want to change the value returned by the method.
Inlining does have it's uses, but I don't think this is one of them.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Sean,

> Win32Error signal: ##(Win32Error fileNotFound)

One subtle potential problem with this occurs if the code and #fileNotFound are
defined in the same package.  It'll work when you first define it, but /may/
fail when you re-load the package.  Since the order of compilation is not
(afaik) defined, the #fileNotFound method might not yet have been compiled at
the time when the in-line expression is evaluated.

(On the main question, I agree with what Ian's already said.)

    -- chris