Scratch

xly wrote:

"family" (or class) variables

That's a great name suggestion!  Thanks.

bharvey wrote:

...bazillion new blocks they invented.

They all have different uses. 

Hmm, I disagree about the three kinds of variables and blocks ("for all sprites", "for this sprite only", "for this sprite's family"). I think it should start out exactly like it is right now, distinguishing just between global and sprite-local. Once a sprite is instantiated it should replace the "for this sprite only" label with something like "for this sprite and its instances".

Sorry to fill up your weekend, but could people interested in the cloning discussion please also read Henry Lieberman's paper, which I think makes an even better case for my model than the Self paper.  Thanks!

Jens wrote:

Once a sprite is instantiated it should replace the "for this sprite only" label with something like "for this sprite and its instances".

You mean, once a sprite is instantiated, familial is the only option?  I am trying to let the user control (on a per-variable basis) whether only variable names propagate (instance variables, as in your model) or whether values propagate too (class variables, as in my model).

Last edited by bharvey (2011-01-16 21:04:30)

@ bharvey - ref H. Lieberman paper

There are dozens of OOP languages, more or less successful (compare bibliography to get an idea of their popularity). They mostly address professional applications, mainly design of Web HM Interface with all the usual tinkery of windows, buttons, pick-list etc

This is definitively not the scope of Scratch/Byob which aims at applications that kids/teens like : adventure game, address game, role player game, strategy game, war games etc How implement new features addressing their needs AND helping them to "raise their ceiling" ? How implement new OOP features while keeping the user-friendliness, flexibility, tinkerability, interactivity and pleasure of programming (ouf) ?

Prototyping+delegation is probably better adapted to Byob applications than classes+inheritance. Generally speaking Byob with its the messaging/multiprocessing capabilities is better adapted to event-driven OOP features. For example RP Games uses extensively events to set up the scenarii. (legacy windows HMI as well).
Just an example : have a new <when broadcast received > adapted for a script integration (contrarily to the Hat control having the same function )...

bharvey wrote:

Carl_ wrote:

The idea is that the jagged list block has the input "all of". That makes it's input the input of the lists. If you press one of the arrows, then it'll get another segment which also has arrows. Basically, it makes sure that you always make a jagged list.

Your "all of" sounds to me exactly like the LIST block. I guess what you/re asking is for BYOB to enforce that a particular input be a list of lists, rather than a list of other kinds of things.

But why do lists of lists deserve special treatment?  There are bunches of blocks that take numbers as inputs, and in order for the operation to be sensible the number has to be a positive integer (like ITEM <> OF <>), but Scratch doesn't provide a special positive integer data type.  If you write a PIGLATIN block that's expecting a word (a text string made of letters) as input, it'll likely do something confusing if given a sentence (a text string including spaces) instead.  But there's no distinguished 'word' data type.

I'm guessing you first learned a strongly typed language such as Java.  The trouble with such languages is that (1) they make it hard to create heterogeneous data structures, like a list whose elements can be of different types; (2) they get the types wrong anyway; "positive integer" is never one of them.

The right approach to typing, if you want to have a typed language, is runtime type checking; you let block definitions attach a predicate function to each input slot, and an error is signalled if the predicate reports false for a given input value.  That way, the user can have "positive integer" as a type, or "jagged list," or "costume that's taller than it is wide," or anything you can imagine.  This is much better than building more and more specific types into the language.

Well, it is a bit like a list block, but it automatically "inserts" the blogs it wants to add, and you can't remove them. Instead you can use the settings that you can use with other block types, like multiple etc. It's not because of typing, but because of for example if/elseif/.../elseif/else blocks. And the input blocks should not have any effect except for packing their input into a list or something.

@ bharvey
I think you should make a toggle advanced blocks button in the options palette so that newcomers would not be scared off but 'oldcomers' could be appeased too by more advanced and fast native blocks.

Last edited by 14God (2011-01-18 02:28:33)

I wonder if the new OOP stuff might make it useful to have more complex messaging between sprites.  Here's a possible scenario.

Sprite "Gun" has a custom block "shoot", and a simple script that executes that command whenever the space bar is pressed.  Wouldn't be great if "shoot" spawned a new "bullet" sprite, by passing a signal to 'bullet' that included x,y, and direction information?  Is this already possible?  And do other people think it's worth implementing?

Thanks,
Matt

bharvey wrote:

bbbeb wrote:

They all have different uses.

Sure.  But, for example, instead of having a block

SET STRETCH TO < >%

and another block

SET VSTRETCH TO < >%

you could just use the regular old SET block and say

SET <_STRETCH> TO < >

This could also potentially replace some of the regular Scratch blocks like

SET X TO < >
SET COSTUME TO < >
SET COLOR EFFECT TO < >

etc.

Oh! like [Set <ScrollY> to (50)]?
I get it, but then you would still need a bunch of reporters, so you could call them all from different areas still.
But, it simplifies the whole "Where is that block I need?" issue in Panther.

titaniumbones wrote:

Wouldn't be great if "shoot" spawned a new "bullet" sprite, by passing a signal to 'bullet' that included x,y, and direction information?  Is this already possible?

Yup!  (Well, as soon as we can spawn sprites from a script at all.)

In the bullet sprite, define a for-this-sprite-only custom block NEW BULLET with inputs XPOS, YPOS, and DIRECTION.  This is where you put the CLONE ME block.  Then, in the gun sprite, you say

LAUNCH [<NEW BULLET> OF <BULLET>] WITH INPUTS <xpos> <ypos> <dir>

That's the OF block in the sensing menu.  First choose the sprite, then the local variables and blocks will appear in the dropdown on the left.

Last edited by bharvey (2011-01-19 01:56:35)

Another experimental version!

Jens wrote:

this version experiments with Lieberman-style inheritance in variables and named lists (in addition to custom-block inheritance):

  1) clones not only inherit the variable name slot, but also the prototype's variable value if they don't shadow it themselves. By default when spawning a sprite the clone copies all variable values and hence they are independent of the prototype's values. However, variable value inheritance is activated by deleting the clone's own named variable.

2) Same thing for named lists.

3) if a clone SETs or CHANGEs an inherited variable, the value-inheritance connection to the prototype's variable gets broken and both variable values become disassociated and independent of each other (the link can be restored by deleting the var)

4) if a clone modifies an inherited named list for which it doesn't have an own one, the prototype's list gets modified. Current existing blocks don't (yet) allow named list slots to be assigned another list.

5) If a watcher is shown onstage for an inherited variable or list, deleting it in the clone does not remove the watcher. Instead the prototype's values are inherited and displayed in the watcher. Each sprite can have it's own watcher for a value-inherited variable (and they'll all get synched automatically), but a value-inherited list watcher only gets shown for the prototype (it can be toggled in each clone), because in Scratch (and currently still in BYOB, too) the watcher is the list.

Enjoy!

Editor's note: This arrived in my inbox about four hours after the email from Jens saying "this will take me weeks!" 

14God wrote:

@ Jens
Would it be possible to make more advanced meshes that allowed multiple connections and cross WAN connections?

it would be exciting to develop the mesh networking feature further, but I'm afraid that I'm currently very much tied up with adding OOP features (prototype based inheritance for sprites) and more first-class-ness. However, you already can connect any number of BYOB sessions over the net, and they don't have to be in the same room.