[kde-edu]: OO syntax code in SVN
tumaix at gmail.com
Wed Jan 28 13:07:54 CET 2009
I'm not a big fan of kross myself, since I couldn't make it work
because of QLists and dinamic propertyes, but I think if there's a
setshape(const QString& s) method that's exposed to kross backed, it
should work without hassle.
is KTurtle multi-language approach implemented as Kross?
On Wed, Jan 28, 2009 at 8:14 AM, Mauricio Piacentini <piacentini at kde.org> wrote:
> 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
> 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:
> 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
> 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
>> 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.
> Mauricio Piacentini
> kde-edu mailing list
> kde-edu at mail.kde.org
Um Computador sem Windows é como um Navio sem dançarinas de Can-Can
More information about the kde-edu