Scratch

bharvey wrote:

shadow_7283 wrote:

This is great! We're in "testing-mode" again! I honestly didn't expect any of this until the summer. 

Yeah, this is way more fun than last semester!  What's a little scary is that we're testing in public while still arguing about the design.  But, I still say, 3.1 release in March, so the summer will be the testing of 4.0.

It should not be an issue for a person like you used "to debug a blank page" as said before.

ATTRIBUTE Instruction is a fantastic one, implementing a very elegant and powerful means to make Inter-sprite communication and command, withoud making any additional variable, method or even function. I like it !

Is there an official release after the October 2010 one?

Jens wrote:

scimonster wrote:

Is there an official release after the October 2010 one?

the BYOB 3.0.8 release is currently still the official one. The newer experimental versions are just that - experiments that will eventually lead up to new alpha, beta and final releases. Everybody is invited to play with the experimental version (although it needs some getting used to for me to share at such an early brainstorming stage), but please don't put too much effort into any serious projects that rely on these experimental features (inheritance, delegation), because things are likely to change a lot before they solidify.

I'm not even downloading the experimental versions, just wanted to ask if there was a new one. maybe there could be an update notifier in the BYOB program, which reads from a webpage, like the Panther news.

You know, even the <true> and <false> blocks could be build.
true:
report [blocks]   <( 1 <=> 1 )>[/blocks]
false:
report [blocks]    <( 1 <=> 0 )>[/blocks]

I suppose they're there so you don't have to make these every time, right?

Last edited by scimonster (2011-01-31 11:02:49)

@ bharvey & Jens

1 - The major interest of OOP languages for the software industry is its ability to build and assemble software components used like a black box (in a way similar to the electronic industry where complex devices are build with many off-the-shelf specialized components) . For the sake of education, Byop should have something similar like export/reimport of prototypes from one project to another one (You have told us that this is not easy )

2 - Once software components are built they need to be assembled together. This is generally done by the means of "software events" . Broadcast is a good approach of event-driven programming. This mechanism could be enhanced to be more OOP-like. For example, a sender sprite (or block) broadcasts something  (name of the sender for example), a receiver executes the necessary action.

3 - ATTRIBUTE capabilities are roughly the same as OF + Method. But its main advantage is to avoid the manual handling of Methods : Make and Set a global variable, Make and Set a local variable.

xly wrote:

Broadcast is a good approach of event-driven programming. This mechanism could be enhanced to be more OOP-like.

IMHO the biggest weakness of BROADCAST isn't that it goes to every sprite; as you say, you can use the sprite's name as part of the message.  The big weakness is that its messages can't take arguments and can't return values.

You'd really like to be able to say something like

SEND <sprite> {FOO LEFT: <5> RIGHT: <7>}

where the stuff in braces is the message, and 5 and 7 are its arguments.  (LEFT: and RIGHT: are part of the name of the message, to remind the user what the arguments mean.)

But we can already do that!  The notation is only a little different:

RUN [[FOO LEFT: <5> RIGHT: <7>] OF <sprite>]

In BYOB a block is a message!  (The "inside" of the block is the corresponding method.)  This is why it makes sense that the script in the Block Editor starts with a hat block whose "event" is a picture of the block itself; a block invocation is an event, and the block's script is event-driven.

(I had to convince Jens about this earlier today, but he's seen the light.    )

bharvey wrote:

(I had to convince Jens about this earlier today, but he's seen the light.    )

Naw, you convinced me to give up my previously rigid views about encapsulation in industrial grade production software in favor of more tinkerability for kids 

(and you're absolutely right about that!)

@ bharvey & Jens - Ref "broadcast"

In the meantime I use the following solution :
When an event occurs for a sprite (hit for example), it sets a Global variable to a list of parameters like sprite name, position etc and broadcast a message (one broadcast name per family). When the master sprite (or any other sprite) receives this broadcast it reads the Global variable and acts accordingly (say, change position, count the hits, play a sound, launch a new target etc)

xly wrote:

@14God Ref " Broadcast/Send"

I like your solution which may be helpful but in other circumstances. I don't want to send an "action" to another sprite (ATTRIBUTE, OF and your SEND do that perfectly), I want to send a list of values to receiver, up to him to do "what it has to do with that". As a sender, I don't care. I'm just a black box and my job is to inform my "chief", the master sprite.

I agree with you that this problem is not a major one, and easy to address with what already exists.

A custom block can be put in the 'send' block and it can process that however it wants based on how the custom block is defined.

bharvey wrote:

14God wrote:

The set variable' block won't take variable inputs. Also you can't declare local and global variables from blocks only script variables.

Yup.  On our list.

Actually I should not have been so glib about this.  I know this is something everyone asks for, but the trouble is that to make it work, you have to generate names for these variables in your script, too, and then you can't just drag an orange blob into your script because the orange blob doesn't exist yet when you're writing the script, so you need something like the Panther generic blob with a text field as its body.  This came up in today's discussion, and we both find it unScratchly -- if you want a text-based language, you might as well use one!

So, while not off the table forever, my current prediction is that this will not be in 3.1.

scimonster wrote:

I typed in = " with a variable after, and it turned into a dropdown that said 1, any, all. Is that a bug?

Sounds like a bug to me, but I can't reproduce it. Where exactly did you type that in?
Thanks!

P.S. I like your SEND block!

bharvey wrote:

14God wrote:

A custom block can be put in the 'send' block and it can process that however it wants based on how the custom block is defined.

Yes, exactly.  That's the point I was trying to make when I said "a block is a message" above.

I really like your SEND block -- very elegant!

I'm a long time user of Inter-sprite communication and I have used it extensively since a long time. I know that I can put into any block any inter-sprite block to send anything to any sprite. But the processing still remains inside the black box. Each time I want to modify the process I have to "open" the black box and modify it internally.

To keep the paradigm of the black box, I'm not supposed to be authorized to open it (think to electronic off-the-shelf components ). I just want the black box to send me outside a relevant  information, needed and sufficient to allow me to make the processing I need. " I Have been hit, I send you the info, up to you to decide the follow-up". Of course I would like my black box more than a simple broadcast and  send me additional info like its position (to send a help service vehicle for example)

This is not blocking issue for me. It's just of matter of "distributed thinking".
One way to walk around this issue : When an event occurs the black box 1-writes a list of data into a global variable, 2- send a broadcast to the master sprite 3 -when master receives the broadcast it extracts the info from the variable and process it. That's it.

xly wrote:

1-writes a list of data into a global variable,

Using globals will cause trouble if two events overlap!