[kde-edu]: [KTurtle] OO syntax code in SVN

[Mauricio Piacentini]

xposting reply to kde=edu as well :)
cies wrote:
 > thanks for your feedback.
 >
 > as mentioned i also think that just putting dots on a turtle object is
 > not "a way forward".
 > is we want to go OO in a way that we can 'help people understand OO'
 > we should at least enable users to make their own objects -- this
 > needs a _lot_ of refactoring of the kturtle interpreter (high costs --
 > i dont think we have the developer time to do so).
 >
 > after too many people complain to me (personally) that kturtle claims
 > to be logo but doesnt adhere XYZ standard/implementation, i broke with
 > 'LOGO'. i dont claim kturtle to be LOGO any longer, kturtle's syntax
 > has since then evolved to be more 'common'. (like {} for scope, $x for
 > vars, etc)
 >
 > i really like what niels did, and what it makes possible, but im
 > afraid that we dont have any OO philosophy so im a little hasitant.
 >
 >
 > learning OO is maybe better to be learned using python or ruby.
 > kturtle is a language for a very small niche, early-education, comes
 > with its own GUI, has a translatable syntax, and gives errors (and
 > help) in the programmers own language. i think our strengths and
 > opportunities are in this dimension, not in different programming
 > paradigms (that is something for an advanced course covering several
 > languages, imho).

Well, it is difficult to comment, specially since I have not helped 
Niels with it. I like the idea of multiple turtles very much, and I 
think it helps fullfill KTurtle's mission, by making it more interesting 
to young students. We can couple it with a new command to let people set 
the turtle's sprite art (via svg files) and suddenly a lot of 
opportunities will open up, even with small games and things like that.

But I do not think using dot syntax helps here. I would prefer to keep 
it procedural. So we would not loose the work Niels did to support 
multiple turtles in the canvas area, but I was thinking about two new 
commands: one to create a new turtle, and another to start "speaking" to 
it. The canvas class would keep a pointer to the current turtle, and 
almost no additions or changes to the language would be needed. There 
would be no object types or changes to the interpreter, only two or 
three new commands. So it would be something like:

//operating on the main (default) turtle
forward 100
turnleft 30
//the next line creates a new turtle and gives it a name
createturtle "daisy"
talkto "daisy"
forward 100
turnleft 30
//we need to define a name for the default turtle,
// here I called it simply turtle
talkto "turtle"
turnright 10
forward 10
talkto "daisy"
backward 10
hide

In this mode, the "show" and "hide" commands will simply operate on the 
turtle we are currently talking to, no changes needed.

Optionally, we could add a command to remove a turtle, but I do not 
think it is really necessary, as we could simply hide it. If we want 
one, it could be

removeturtle "daisy"

For all the other commands (pen for example) we could take two routes: 
keep different states for each turtle, or keep a global canvas state. I 
would prefer to keep it global, as it is more procedural to me, but both 
could be handled more or less easily without changes in the language or 
interpreter, only keeping states in the canvas class for each turtle.

The other command I was thinking about in the past was one to change the 
svg element or image, and coupled with this ability to talk to multiple 
sprites we could implement small games and animations. I was thinking 
about a

setImage "bird"

function that would operate on the current turtle. With it (and the 
talkto or tell command) we could do something like is described in the 
Up and Away section at the bottom of this page:

http://el.media.mit.edu/logo-foundation/logo/turtle.html

I think something like this still keeps the procedural model pretty much 
in check, while expanding the features of the program a little bit and 
adding several new dimensions for teachers to exercise.

But there are two separate issues. Anywasy, I can volunteer to work a 
little bit on it for 4.3, specially if we take this route where most of 
the work is concentrated on the canvas and QGV, as my grasp of the 
interpreter is not good enough to work on stuff like implementing new 
object types :) I leave these more complex bug fixes to you guys!

Best regards,
Mauricio Piacentini