Scratch

joefarebrother wrote:

"On-screen object"?
"Visible object"?

Same issue as "Drawable" — Kurt's not actually drawing them on the screen, so they can't really be thought of as being "on-screen".

bharvey wrote:

Or you could forget about theater metaphors and just call them "blobs." 

That's not helpful 

nXIII wrote:

blob8108 wrote:

I'm working on the Kurt 2 API, and I need a good name for "things that can go on the stage", which is the superclass of variable/list watchers, stage, and sprite. My ideas so far aren't great:
* "Object" -- gets confusing.
* "Drawable" -- sounds like it's related to images (and Kurt doesn't draw them anywhere anyhow).
* "Morph" -- is morphic-specific (though it's currently the best option).

Any suggestions?

ScriptableScratchMorph. 

Joking aside, as long as Object is in a reasonable module, I don't think it would get too confusing.

You could also call them Things.

#Object, you forget it's written in python, where 'object' is a built-in

roijac wrote:

nXIII wrote:

as long as Object is in a reasonable module, I don't think it would get too confusing.

#Object, you forget it's written in python, where 'object' is a built-in

It would get slightly hard to distinguish, when half my classes inherit object, yeah... 

bharvey wrote:

@nXIII:  Read your email!

I did! I just haven't had a chance to ask yet.

roijac wrote:

nXIII wrote:

as long as Object is in a reasonable module, I don't think it would get too confusing.

#Object, you forget it's written in python, where 'object' is a built-in

No, I didn't. Object is built into JavaScript as well. That doesn't mean you can't call something scratch.Object!

Last edited by nXIII (2013-03-30 18:40:50)

bharvey wrote:

@nXIII:  Read your email!

@bharvey and Jens: did you read yours? Or were you taking a weekend break (which is totally fine—I blank out on the weekends a few times a month just because I can  )?

#Naming objects (yes, I have given into the twitter-style discussion motif. Sue me.    ): How about Entity?

(EDIT: That's not a double-sad-smiley, that's an emoticon, then the end of a parenthesized statement and a colon.)

Oh, and I think I'll use the stage-actor-props metaphor to explain Scratch to newbies, so check back in like 30 hours.

Last edited by Hardmath123 (2013-03-31 04:57:55)

Hardmath123 wrote:

Well, in Python, you would run into problems when coding a module:

It wouldn't be a problem in that it would /work/ -- names are case sensitive, after all -- but it would be hard to quickly distinguish.

Not that I haven't named the base drawable Object in my Python game engine... 

blob8108 wrote:

Hardmath123 wrote:

Well, in Python, you would run into problems when coding a module:

It wouldn't be a problem in that it would /work/ -- names are case sensitive, after all -- but it would be hard to quickly distinguish.

Not that I haven't named the base drawable Object in my Python game engine... 

And I used it instead of Primitive for my raytracer.

How about Primitive? 

Hardmath123 wrote:

If you happen to find that network, let me know!

roijac wrote:

Hardmath123 wrote:

blob8108 wrote:

Hardmath123 wrote:

How about Entity?

Hmm, that's a thought. I'm leaning towards Actor, I think, as it's closest to "thing-on-a-stage". (I could just use that, of course...  )


Let us know how that goes -- if it works, then I'll use Actor!

Sure. I suppose tomorrow will just be installing Scratch, so you may have to wait till Tuesday. I have an awesome setup to do so: I'm hosting a twisted server on my mom's Mac which serves all the files you need to download. Our Wi-Fi is shared through Mac internet sharing with network name GameClass.

(If you happen to find that network, let me know!)

I still think that some USB sticks will do the job just fine 

So does my dad… come on, don't you think this is infinitely cooler? People log on to 192.168.1.7:8000 and voila!

Hardmath123 wrote:

roijac wrote:

Hardmath123 wrote:

I have an awesome setup to do so: I'm hosting a twisted server on my mom's Mac which serves all the files you need to download. Our Wi-Fi is shared through Mac internet sharing with network name GameClass.

I still think that some USB sticks will do the job just fine 

don't you think this is infinitely cooler? People log on to 192.168.1.7:8000 and voila!

It is cooler! But why the Twisted server -- don't Macs come with Apache?So you could just drop the files into /Library/WebServer/Documents and enable Web Sharing...

And assuming your peeps are on Macs or have iTunes installed, you could use Bonjour to save typing out the IP! (http://mums-mac.local/...)

blob8108 wrote:

joefarebrother wrote:

"On-screen object"?
"Visible object"?

Same issue as "Drawable" — Kurt's not actually drawing them on the screen, so they can't really be thought of as being "on-screen".

Maybe you could call them,programmable objects?
Views?
Components?
Scripted objects?
Visible objects?
Movable objects?
On stage objects?

blob8108 wrote:

I might need a superclass for both Script and Comment (for free-floating comments), as they're both things that can be added to the scripting area. Any thoughts?

Since comments can be attached to scripts, I've always thought of free-floating comments as being attached to empty scripts.  A comment is just another kind of block that connects sideways instead of vertically.

Block("say [Hello!] for (2) secs"), rather than the uglier Block('say:duration:elapsed:from:', 'Hello!', 2).

Yes of course that's way better!

But I'm not convinced that the format can be easily (and automatically) extended for new formats, Snap! especially.

I have every confidence in you.

Snap! scripts are basically "nested tuples with the command name as the first item", the same as Scratch, right? (Is "S-expressions" the technical term?)

I think you mean "Snap! instructions" not "Snap! scripts."  A script is a sequence of instructions.  An instruction (a name nobody's used in this context before that I'm importing from Logo documentation) is a filled-in command block.

In Lisp, every expression returns a value -- in Scratch terms, all blocks are reporters.  So applying the term "S-expressions" to Scratch/Snap! is slightly tricky, because we have to distinguish between an instruction (a filled-in command block) and an expression (a filled-in reporter block, or a number or string).

Jens is turning in his bed as I type this (not having a grave to turn in, still being alive) because in his mind (and to an extent in the implementation(s)) there is no distinction between a block and a script.  This is basically because instead of the Lisp style of representing an expression, as a list formed of pairs whose car is a pointer to an element and whose cdr is a pointer to another pair of the list spine, Morphic blocks (corresponding to the elements of an S-expression) include the pointer to the next block as an internal field.  So every block includes the part of the script that comes below it.  This fits with the UI feature that when you grab a block, you end up dragging it and everything below it in its script.  Also, in Lisp there is a very sharp distinction between a procedure and the invocation of a procedure in an expression, but in Morphic a palette block (the closest analog to a Lisp procedure) is the same data structure as a block/script in the scripting area -- much to my dismay.  It's done this way because the evaluator's data structures are primarily serving the needs of the UI display, and secondarily useful to the actual evaluation.  If it were up to me, there would be a distinct thing called a procedure that would not be a Morph at all -- it'd be invisible -- and the Morphic blocks would be expressions invoking the procedure.  But, if it were up to me, Snap! wouldn't be written yet, so I don't get a vote. 

EDIT:  The widespread use of default input values in primitive blocks blurs further the distinction between a procedure and an expression.

Last edited by bharvey (2013-03-31 17:30:58)