Re: OBJECTS.FS Question

Anton Ertl wrote:
> Doug Hoffman <no.spam> writes:
>> If I then make a snapshot image of my Forth system and re-launch that I

>> am unable to get my object x to do anything.


> objects.fs uses
> ALLOCATE and RESIZE to store some of the data on cl*****, and that
> would then be lost.  I guess that's the problem you see.

That's a significant problem to deal with.  A problem that the Neon-like 
model doesn't suffer.  It would have been a more balanced paper had you 
brought these facts out in your "Yet another Forth objects package" 
http://www.complang.tuwien.ac.at/forth/objects/objects.html
especially 
since your prior paper was unduly and inaccurately critical of the 
Neon-like model (that paper was titled "On Standardizing Object-Oriented 
Forth Extensions" but in reality was a rant of Andrew McKewan's work on 
the Neon-like model for Forth. For other readers, see 
http://www.complang.tuwien.ac.at/forth/objects-standard.html
).

In the "Standardizing" paper there was quite a bit that I didn't follow. 
  For example, you make an issue of McKewan's use of state smart words. 
  Why not just point out that the Neon model is easily written without 
them?  Took me less than 5 minutes to do so.

You make issue of the relative speeds of late binding, calling McKewan's 
"inefficient" just because it is a bit slower than a vtable.  In an 
Olympic sprinting race, would we call the silver medalist slow? 
Actually, I was able to speed up McKewans late binding code.  It uses an 
8-way linked list (instead of a single-way) but he was waiting to 
compute the 8-way until run time.  This calculation can be done at 
compile time and speeds things up noticeably.  I have done so.  A linked 
list search is still very fast.  It can be made faster yet by writing 
the routine in assembler.  It's a simple routine.  I don't like 
assembler but even I was able to easily write that.

A serious flaw with Objects.fs is the use of late binding when the class 
of the object is known at compile time.  Like SWOOP, the Neon-like model 
defaults to the extremely fast early binding in those cases.  That's why 
the Neon-like model typically outperforms Objects.fs in real world code. 
  It is also why, IMO, one sees more method factoring in class 
definitions using the Neon or SWOOP early binding default.

The ancient debate of the ordering of object and message seems to me 
irrelevant and a bit silly to obsess over.  For one thing the Neon model 
can *easily* do it either way.  As far as the ordering being natural or 
Forthlike  or non-Forthlike:  We seem to get along just fine with the 
locals syntax ( parameter-message-object ).  Forthers will similarly 
have no problems at all doing the same for objects.


>>  Worse, I cannot even reload the above code 
>> starting with 'interface selector val ...'.
> 
> There is already something stored in ALLOCATEd memory when you include
> objects.fs (in particular, parts of the definition of the OBJECT
> class).
> 
> Should we change the Forth systems to also save ALLOCATEd memory,
> should we change applications and libraries to avoid ALLOCATEd memory,
> or should we just be happy with loading applications from the start on
> every startup (and make the systems compile fast enough)?

Neither.  We could use a different Forth OOP extension that doesn't 
suffer this serious problem.

-Doug


> 
> - anton