Scratch

14God wrote:

bharvey wrote:

You should be able to say, e.g.,

Code:

SEND <other-guy> [SET <his-variable> TO [ASK <me> <my-variable>]]

I also realized that the send block will use script variables from the senders scope.

And yet a third solution, probably best of all, is


This way all the args are evaluated in the sender's environment.

@ bharvey & Jens

I had written sometimes ago : "For the tree-structure what about a structure of Sprites of Sprites like now for Costumes of Sprites, easily added, deleted, activated, imported, exported?" This is definitively stupid. But what about a solution similar to the one used for nest sprites whereby one sprite is linked to any other one. This allows to define  a  flexible "network" of sprites (a far better structure than a tree).

A network for what ? To define a structure of owned/shared/inherited methods/data.  But does this still means anything considering that ATTRIBUTE instruction allows to use any function, (even local) anywhere, for any purpose (of course under control of the programmer). And the same for semi-persistent variables which can be SET and GET to and from any sprite for any use ( like in my demo project as to couple broadcast and data-sharing ).

bharvey wrote:

14God wrote:

bharvey wrote:

You should be able to say, e.g.,

Code:

SEND <other-guy> [SET <his-variable> TO [ASK <me> <my-variable>]]

I also realized that the send block will use script variables from the senders scope.

And yet a third solution, probably best of all, is
http://cs.berkeley.edu/~bh/send.gif

This way all the args are evaluated in the sender's environment.

I tried that and for some reason it didn't like that and wouldn't take the arguments :\
better just to use script variables and pass them in to your command. (the script variable block won't work if you stick it directly in the send block so just put it above the send block.)

Not that I would ever spam the BYOB thread, but the working demo of the Haiku interpreter we were talking about months ago is almost ready to go! Here's a *working* code example demonstrating how to write a Person class:

Person = |first,last|{
    //Assign the constructed object to variable '@' for reference and return it
    ^(@ = #{
    firstName:first
    lastName:last
    introduceSelfTo:|other|{
            if(!other is("Person")){
                //Not a person object :(
                ^false
            }
            ^"Hello, "+other firstName+"! my name is "+@ firstName+" "+@ lastName+"."
        }
    } setType('Person'))
    //The setType(), getType(), and is() methods work as a duck-typing system
}

john = Person('John','Deere')
jane = Person('Jane','Doe')
john introduceSelfTo(jane)

Link coming soon, I promise.

bharvey wrote:

rubiks_cube_guy238 wrote:

Ooh! I just noticed that there's a layer option in the get and set blocks! I don't see how this could be used, but it might lead to something...

People are always complaining that there's GO BACK <n> LAYERS but if you want to go frontward you have to go all the way.  So, now you have complete control.  You can tell each sprite to go to a specific level number, instead of having to worry about the order in which they run their GO TO FRONT scripts.

You can just put a negative number in, but nice!

.... "Functionless Byob"

Reversedly, although the motion variable bumpvar is defined as local into Main, it can be activated from any other sprite to move any other sprite, by the combination of ATTRIBUTE + OF !!

RUN [ATTRIBUTE [bumpvar of Main ] OF Anysprite]

What becomes the notion of inherited/local/global methods or variable in such a situation ? Aren't you inventing a totally new way to make OOP ?

fullmoon wrote:

a :(12)

What's the colon for?

@ Jens
What are you working on in BYOB right now?

I haven't been on the forum much over the last few days because my cousin came over and we had to clean the house and then I got a head ache today.

14God wrote:

I haven't been on the forum much over the last few days because my cousin came over and we had to clean the house and then I got a head ache today.

Bummer!  Me too.  (The headache part, although I guess I should clean the house too.    )

But you know what Jens is working on -- you've been seeing almost-daily releases!

xly wrote:

.... "Functionless Byob"

Reversedly, although the motion variable bumpvar is defined as local into Main, it can be activated from any other sprite to move any other sprite, by the combination of ATTRIBUTE + OF !!

RUN [ATTRIBUTE [bumpvar of Main ] OF Anysprite]

What becomes the notion of inherited/local/global methods or variable in such a situation ? Aren't you inventing a totally new way to make OOP ?

Hi Xavier,

are we inventing a new way for OOP? Well, I hope so! I also hope that it will help children and college students get a better of understanding of how OOP works, and that we don't mess up completely 

As Brian as been pointing out, prototype based inheritance isn't a new idea at all, and, in fact, it's the way in which the world's most popular (arguably) programming language (JavaScript) handles OOP. If I understand you right, you're fascinated by being able to run one sprite's script in the context of an arbitrary other one. Come to think of it, this, too, isn't such a far-fetched idea, if you consider scripts to be just that - data like anything else.

But I have to caution you about open-ends in the current pre-alpha versions: Right now you can even run one sprite's local custom block in the context of another sprite which doesn't share it's definition. If you do that the target sprite will, in fact, copy the "sender's" block definition locally. That's a bug I'm going to fix in one of the next releases, so please don't depend on it. You're absolutely right in pointing out, that only sprites which are linked to another should share block definitions.

Thanks for all your thoughts and feedback!

@ Jens .... "Functionless Byob"

Of course the versatility of Byob can't be detrimental to its component-ability still under work. Today, a project becomes messy after a short while for at least 2 reasons  1-easy duplication multiplies the risk of anarchic duplication of blocks 2- the bad usage of "Import project" ( as to not rewrite your usual blocks each you start a new project ) because presently the export/import of sprites does not work correctly. As a result sometimes functions (or blocks) have the same name but not the same code. When one block is changed/updated you never know which version you are modifying.

From by small window I see 2 solutions 1 - add a surname to the name of blocks (like a local variable displayed on the stage where is added the prefix of its sprite ). 2 - as much as possible dedicate a sprite to be a block library. Doing so I was surprised to succeed in exporting/re-importing a sprite containing my most usual blocks !