How effectively to implement method #inc?

Hi all!
Pls help, I'm newb in Dolphin ST.
How effectively to implement method #inc (increase self value) for
SmallInteger class?
Class defenition of SmallInteger have not "instanceVariableNames". I dont
undestand where it hold value and how i can increase it.

Thx

Hi Pavel,

> How effectively to implement method #inc (increase self value) for
> SmallInteger class?
Short answer: You can't.
Long answer: SmallIntegers are literals in Smalltalk - i.e. instances of
SmallInteger do not hold their value in an instVar ... they ARE the
value (value is encoded in Object Pointer; see here
http://users.ipa.net/~dwighth/smalltalk/bluebook/bluebook_chapter30.html#ObjectPointers30).

You could however do something like this:
SmallInteger>>increase
        ^self + 1

But this whill return an increased (copy) SmallInteger and will not
change the SmallInteger you sent the message to.

All the glory details are here:
http://groups.google.com/group/comp.lang.smalltalk.dolphin/browse_frm/thread/293ca33c0d1a1461/3033d96670cdf268?q=literal+number&rnum=2#3033d96670cdf268

CU,

Udo

Pavel wrote:

> How effectively to implement method #inc (increase self value) for
> SmallInteger class?
> Class defenition of SmallInteger have not "instanceVariableNames". I dont
> undestand where it hold value and how i can increase it.

You can't.  A SmallInteger doesn't /hold/ a value, it /is/ a value, and it
cannot be changed.

If you have code like:

    i := 27.
    i := i + 1.

then you aren't incrementing 27, you are replacing the value held by the
variable 'i' with a new value (28 in this case ;-).

You can of course, define your own kind of object which /holds/ an integer, and
which responds to the #inc message by replacing that integer with the next one
higher. Sometimes there are good reasons to want to do that kind of thing.

(There was a thread a little while ago which discussed various hacky ways of
acheiving the effect.  Some are clever, some are interesting, but none have any
relevance at all here -- or so it seems to me).

    -- chris

Chris Uppal wrote:
Actually, this has some interesting philosophical aspects w.r.t. object
identity. Is an object the same if it #become:s another object? What are
the identifying characteristics of an object? I'd be interested in
hearing Blair's comments, especially since he was on the ANSI committee
(or at least that big fat x3j20 doc I have on my bookshelf says so :-)

Cheers
Joseph

> Long answer: SmallIntegers are literals in Smalltalk - i.e. instances of
> SmallInteger do not hold their value in an instVar ... they ARE the
> value (value is encoded in Object Pointer; see here
Hmm...  may be possible affect Object Pointer ? What undesirable
consequences it can give ?


> You could however do something like this:
> SmallInteger>>increase
> ^self + 1
>
> But this whill return an increased (copy) SmallInteger and will not
> change the SmallInteger you sent the message to.
>
yes, It's I understand :)
Just interesting,  if "evrything is object" in ST ( and this very cool and
becouse ST very attractive for us :) ) ,
Just It's may be usefull practice - Hold many references on SmallInteger
object ( "evrything is object" in ST ) and I want to affect THIS object, and
all other ref see new value...     Or for this case I must create new class
MyInteger ?

PS. sorry for my English

Well... some objects are inmutable.

Numbers is an special case, because what is "3"?[*] (what is a
number?).
[*] http://en.wikipedia.org/wiki/Number_0

They're unique, in the identity meaning.
You can't become 3 to 4 in smalltalk, nor in the world.

As in the old thread Udo pointed, and as Chris stated before (and many
others too) that behavior would correspond to aVariable or value
holder, not to a number.

If you like to do it, and really need it, you can have a number holder,
which acts as proxy between the sender and the actual number. And will
define all that behavior.

However, the main question of this thread is naive. So the answer isn't
incorrect, the question is.

Best regards,

--
Esteban

Everybody who reply tnx alot!!!
I just meditate about whats more effectively   :

a:=1.

1.   affect objects value something like:
 a inc.  "As it was found out - It is impossible (no simple effective way )"
2.   or
 a:=a+1. " just i believed its have overhead of new object creation, and
affect them"

My Conclusion: operation with integers like  a:=a+1   are fast enough (no
overhead new object creation etc) .
I have correctly understood?

PS, sorry for my English... and may be newb's questions...

Pavel wrote:

> Just It's may be usefull practice - Hold many references on SmallInteger
> object ( "evrything is object" in ST ) and I want to affect THIS object,
> and all other ref see new value...     Or for this case I must create new
> class MyInteger ?

Yes, that's what you must do.  By the way, for many purposes where you want to
have a shared object which has a value that can change, the class ValueHolder
is appropriate.  That's mainly intended for use in GUI construction (as are the
other subclasses of ValueModel) since it generates change events automatically
as its value is changed.


[from a different post]

> My Conclusion: operation with integers like  a:=a+1   are fast enough (no
> overhead new object creation etc) .

Well, they are as fast as they can be in Dolphin.  If you need to do huge
numbers of additions (hundreds of millions), then Dolphin itself may not be
fast enough, but normally addition (and so on) is quick enough that you don't
need to think about it.

It's worth (perhaps) mentioning that when the integers get bigger (more than 31
bits) Dolphin will switch automatically to using LargeIntegers, and that is
somewhat slower since LargeIntegers /are/ allocated for each arithmetic
operation.  Still, doesn't make much difference in practise for most purposes
(especially since arithmetic on >32-bit numbers is going to be slower anyway,
even without the allocation, no matter what language you use).

Floats are allocated too, and that /can/ make an important difference, since
it's not so uncommon to need to do a /lot/ of floating-point calculation (doing
a FFT for instance) and in such cases the overhead of allocation can be pretty
serious.  But then, in such cases, you wouldn't want to write that part of the
program in Dolphin anyway -- you'd write it in Fortran (or, at worst, C or
C++), and package it as a DLL that you can easily call from Dolphin.  That's
only worthwhile if you are doing a lot (many millions) of floating point
calculations, of course -- there's no reason to avoid floating point
calculations for normal purposes.

Just to make this concrete, here are some numbers.  An empty loop:
    k := 0. 1000000 timesRepeat: [k := k]
takes around 32 nanosecond per iteration on my (1.5 GHz) machine; making the
loop do one more addition each time:
    k := 0. 1000000 timesRepeat: [ k := k + 1]
increases the time taken to about 35 nanoseconds, so each SmallInteger addition
is taking about 2 nanoseconds.  If I change the loop so that it uses floating
point:
    k := 0.0. 1000000 timesRepeat: [ k := k + 1.0]
then the addition takes almost 50 nanoseconds.  So floating point addition is
significantly slower than integer addition.  On the other hand, it still only
takes 50 nanoseconds, so even a million calculations would only take a
twentieth of a second -- which is too short for a user to notice.

    -- chris

Thank you alot Chris!


-- Pavel