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...
squeak-dev@lists.squeakfoundation.org