Agree:

> > Andrew, David (thank you for the hint with the compile times) >
> and Dean have
> > favorized Plugins as implementation choice (for different reasons).
> > > I think this is a possible variant which makes sense, too. >
> But also I think
> > that's not the main point:
> > - it should be possible for a non C-freak just by reading sources in
> > Smalltalk to get a working idea how its possible to make LargeInteger
> > computations in Smalltalk
> > 	=> this is the didactic approach;
>
> Plugins, as various people have proposed, would be written in
> Smalltalk, in Squeak.
>

You are right. I'm just thinking sometimes in the world of so called 'user
primitives' written for a VW-image some time ago...

> > - its interesting to have LargeInt arithmetics __as fast as possible__
> > without the coercion to follow the 'didactic' implementation line
> > 	=> cryptographic, maths, random generators, advertising >
> (for people who
> > compare Squeak with other Smalltalks);
>
> Plugins should have no meaningful overhead, particularly if
> implemented as byteArrays.
>

It's the first step and possibly good enough. But I'm not so sure that
ByteArrays are the end.

The 'didactic' approach should be the standard implementation in the
standard classes (with less changes as possible), not the eventually more
tuned Plugins. And now - after these discussions - I would not remove the
'didactic' standard code for a primitive (e.g. for saving image space). The
intent for me is to point out the importance of understandability of basic
concepts. I don't bother about a few bytes of mem more or less (correct
English?). And reading source code in plugins is possible of course and at
first similar to the current implementation. But it's not a full and
specialized (in style) Smalltalk and therefore a kind of indirection, isn't
it?

> > - then it should be as portable as possible, so don't try >
> near assembler
> > programming.
>
> Again, plugins should be highly portable.  Frankly, I don't
> understand Stephan's objections on any of these points.

I know that plugins should be highly portable, but there were some other
mails, too, and I wanted to give kind of a summarize.

>
> > Some personal remarks:
> > I want to start this around mid of November (then I have some >
> holidays, now
> > I'm working for money and writing these mails ;-)). But after >
> start I have
> > to
> > - compile Squeak first;
>
> Why?

To become familiar with the environment.

>
> > - understand the plugin mechanism with a simple example, not >
> 'primitive' ;-)
> > example, what I first have written;
>
> Examples can be found in the image.  There is also some doco on the Swiki.
>

Ok, but at least for me there is a way from
- just seeing a new system,
- become familiar with it,
- try this and that and then
- become productive.

And please do not underestimate the costs - my costs, if you want - _beside_
the core problems!

By the way: it's interesting to come back/forward to other paths after one
year VC++6.0...