[kde-edu]: OO syntax code in SVN

[Mauricio Piacentini]

cies wrote:
> i dont know guys..
> 
>> extra inspector window [...] to show the
>> turtles and their positions.
> 
> doesnt sound like a good idea to me.
> 
> multiple turtles is a neat feature.
> 
> about the syntax, my take is go full procedural, reasoning:
> if we cannot deliver full-OO -- lets not deliver any OO.
> 
> 
> we dont use the word "turtle" in any of the command, do we?
> (i never wanted to do so because we might get different 'sprites' later)
> so adding the commands "clonesprite" and "talkto" is maybe a good one.
> 2 extra keyword that do everything. no names :-)
> talkto 0 # talk to the default sprite
> talkto 1 # first clone, etc.
> 
> i think that makes most sense if we _really_ want multiple sprites --
> quite a nice feature.

I am not sure if it is easier for children to remember the index of each 
turtle or to call them by name. Some research using similar languages 
shows that some use indexes, while others use names. The ones that use 
indexes do not usually require a create command, you just start talking 
to the other turtles, for example

talkto 1
show
...
talkto 0

So no need to create them. Our code could be easily adapted for this, by 
checking if a given turtle exists, and if not creating it. These 
languages usually have a limit for the number of turtles, around 1024.

Another approach is to create the sprite using a command. There are 
several implementations for this, using variations of:

NEWTURTLE
CREATESPRITE
SETSPRITE

But if we really want to keep it dead simple, maybe just document that 
internally we have up to 1024 turtles, and only the first one is shown 
by default. To use the others, just

TALKTO 1
SHOW

and here you go. So no concept of "creation" of objects, and no explicit 
turtle in the command.

> 
> buttt... i think there is more important features to implement for kturtle:
> - contextual help still not in
> - errors tab could get some beautification (like spacing the errors
> table nicely)
> - contextual error help would be a killer
> - maybe even the variables tab should have contextual help
> (so it is integration with the help system where is see most low
> hanging fruit for making steps towards kturtle 'goal' of making
> programming something dead easy to start with)

Yes, this would be really useful.

> besides that we have some bugs piling up...
> 
> the big change is in the interpreter though -- i would love to have a
> generated parser, and if i look at the design of KJS i see many room
> for improvement on the interpreter side (the ruby i wrote for
> definitions.rb is, ehhh, not the prettiest to say the least). the main
> thing we have to do _before_ the interpreter can get an other big
> cleanup:
> 
> unittest
> 
> 
> that are the priorities the way i see 'm..
> 
> dont worrie KTurtle is a free software project -- together with make
> kturtle's future, so if you have a different idea about the priorities
> for future development of kturtle, please post it here :-)

I am not really an expert in computer languages or interpreters, so my 
ability to help here is a bit limited... I can see also that some 
features (like implementing SETSHAPE to change the turtle graphics) 
would open up a lot of new potential, but also several new problems. It 
has to be done in a way that does not affect the portability of code, 
for example. I will write a proposal for it.

Regards,
Mauricio Piacentini