to learn Smalltalk I'd recommend browsing Squeak.org, they've got plenty of excellent material. For a very dense "postcard" check http://esug.heeg.de/whyusesmalltalktoteachoop/smalltalksyntaxonapostcard/
Offline
Today's 3.1 alpha bugfix release.
Jens wrote:
Tonight's build fixes the following bugs and issues:
1. double clicking on the CLONE block in the palette (not in the scripting area) no longer throws an exception.
2. the OBJECT block's drop down menu now has an 'all sprites' option, which when invoked returns a list of all sprites (without the stage)
3. switching a child sprite to another parent now causes the child to immediately inherit the new parent's costumes and sounds (if it doesn't hold its own private wardrobe or jukebox)
4. Deleting a parent sprite now causes all of its children to become independent (bugfix)
5 the EDIT menu now has an option to "Clear All Variables". This, umm, clears all variables and lists in the project. Since BYOB is relying on Scratch's file format structure the whole first-class business (which Scratch wasn't designed to support) can lead to circularity in data structures. BYOB can handle such circularity, but will sometimes fail trying to save such projects. Clearing all variables and lists solves this (at the cost of loosing project state). This - kludge, I admit - lets you save the complex OOP example in the new manual after you've run it.
Enjoy!
--Jens
Offline
BUG:
http://screencast.com/t/nh6CstWVy
I was able to recreate it every time I tried, so I'd say it's not a very rare bug.
Last edited by ScratchReallyROCKS (2011-02-24 21:39:05)
Offline
Jens wrote:
Hmm, I can't reproduce this bug. It works for me.
Really? Weird. I'll try again...
Okay, I guess it's a lot simpler than I thought it was:
1. drag in two "the script" lambdas, each with 1 input name. The input names MUST be the same for this bug to work. I just stuck with the normal "#1", but it works with anything.
2. click the left arrow on one of the lambdas, deleting the input name.
3. do the same on the other, and you get a "key not found" error.
4. (optional) click the left arrow again, and you get a "message not understood: delete" error, or click the right arrow and you get a "message not understood: owner" and it will delete anything in it's C stack.
Last edited by ScratchReallyROCKS (2011-02-25 11:15:41)
Offline
Hey, gang, here's today's radical proposal: What if we removed "duplicate" from the sprites' context menus, so "clone" would be the only sort-of-copying option? I'm thinking having only one way to semi-copy a sprite might be less confusing. Does anyone still want "duplicate" now that you have "clone"?
P.S. It wouldn't break old Scratch projects, because you could never duplicate from a script, only from the GUI, so any duplicates they want already exist in the project file.
Offline
bharvey wrote:
Hey, gang, here's today's radical proposal: What if we removed "duplicate" from the sprites' context menus, so "clone" would be the only sort-of-copying option? I'm thinking having only one way to semi-copy a sprite might be less confusing. Does anyone still want "duplicate" now that you have "clone"?
P.S. It wouldn't break old Scratch projects, because you could never duplicate from a script, only from the GUI, so any duplicates they want already exist in the project file.
I don't like that idea. Often I want to copy a sprite but make *major* changes to it - rather than the common assumption of duplicate being used to have a 100 sprites for a single task. I don't think we should have to resort to the tedious task of creating a new sprite, copying the sounds, costumes, and scripts, and in some situations, local variables.
Offline
Lucario621 wrote:
I don't think we should have to resort to the tedious task of creating a new sprite, copying the sounds, costumes, and scripts, and in some situations, local variables.
Everything in that list except local variables will just do what you want. Local variables will, too, provided you change the child's value before the parent's value. Try using cloning in some project where you would otherwise use duplication and tell me how hard it is in practice.
Last edited by bharvey (2011-02-25 16:08:21)
Offline
bharvey wrote:
Lucario621 wrote:
I don't think we should have to resort to the tedious task of creating a new sprite, copying the sounds, costumes, and scripts, and in some situations, local variables.
Everything in that list except local variables will just do what you want. Local variables will, too, provided you change the child's value before the parent's value. Try using cloning in some project where you would otherwise use duplication and tell me how hard it is in practice.
Yes, but I don't want any parent values to be kept! At all!
Lets say I have some kind of adventure game. I made one monster sprite. I duplicate it, and I the second one as a base for my second monster. So I keep the attack formula script, but I change the stats, costumes, sounds, and special moves. Now why should we have to clone for all of that?
Arguably, for most people, especially new scratchers, it would be simpler to just have duplicate (although cloning is possible).
Last edited by Lucario621 (2011-02-25 17:16:50)
Offline
@bharvey and others - remove duplicate
I'm not favourable to your "radical proposal". The OOP new stair that you have just added to the 1st-class stair should remain optional for users who don't care to write OOP-compliant applications, even if they appreciate and use most of the new features added.
What you have just achieved, Brian and Jens together, amongst many other things, is that without modyfying the initial Lego-like Scratch, you have added two new levels of sophisticated programming tools , 1-st class and OOP by adding to Scratch less than 2 dozens of new instructions ( I can imagine all the work behind the scene to come to such a result).
As far as Clone instruction is concerned I am not sure that it is a good idea to limit CLONE to the current sprite. If you replace the verb MAKE ( a new sprite) instead of CLONE ( a new sprite which is my twin copy), then <CLONE anysprite> can be a useful command if executed by any other sprite different from <anysprite>.
Offline
Perhaps we should REPLACE the "duplicate" option, rather than eliminate it completely. Instead of duplicating a sprite, the option "clone" would prototype it. This way, the option would introduce first class to new "Snap"'ers without really eliminating any functionality.
Just a thought.
Offline
shadow_7283 wrote:
Perhaps we should REPLACE the "duplicate" option, rather than eliminate it completely.
You mean, call it "duplicate" but have it really make a clone?
new "Snap"'ers
Otherwise known as "whippersnappers"?
Offline
bharvey wrote:
You mean, call it "duplicate" but have it really make a clone?
Sure, or rename it and have it serve a similar function. I'm not sure what it should actually be called...
bharvey wrote:
Otherwise known as "whippersnappers"?
Offline
@ bharvey & Jens
When i started to play with Byob 10 months ago I started to play with methods stored in a list. Ok it works, Perfect for the 1-st class theory, but the result is very slow and quite unusable in practice. I think that the reasons stands in the general bad performance of list handling in Byob.
I doubt that Snap-ers will be inclined to use a full OOP deployment as you explain page 32 of your updated Byob tutorial due to performance limitations.
No need to say that for educational and teaching aspects these new developments are very useful, making Byob converge to cl
Offline
... converge to general purpose lambda languages ( see for example implementation of OOP in PH Winston "Lisp" published in 1981 !)
Nevertheless the new instructions introduced for OOP reasons are very worthy for many applications even if they are not OOP compliant.
ps - Jens , where can be found the EDIT you are talking in view of "project sharing " ?
Offline
xly wrote:
the result is very slow and quite unusable in practice. I think that the reasons stands in the general bad performance of list handling in Byob.
Yes, we know. And we know how to fix it. It'll certainly happen in 4.0 this summer, and maybe we'll even have time to improve things somewhat in 3.1, but probably not -- only two weeks to go.
But for sure in 4.0; that's the main reason we're doing a complete rewrite!
P..S. I think of all our work so far as just a "proof of concept" and a design exercise. 4.0 will be the first real implementation.
Last edited by bharvey (2011-02-26 12:31:26)
Offline
Jens:
Here is the completed class.js for Morphic. I tested it in IE 8, Chrome 10, Firefox 3.6 and 4 beta, and Safari 5. Change "development: true" to false in the options at the bottom to prevent it from making toStrings and documentation for the classes.
Excessively long example:
Class('Automobile', { construct: function(color) { if (color) this.color = color; }, properties: { color: "black", wheels: 2, paint: function(newColor) { this.color = newColor; }, log: function() { alert("A " + this.color + " automobile with " + this.wheels + " wheels"); } } }), Class('Car', { sup: Automobile, construct: function(color, year, model) { this.sup(arguments); if (year) this.year = year; if (model) this.model = model; }, properties: { wheels: 4, model: "Cooper S", year: 2012, color: "red", paint: function(newColor) { this.sup(arguments); alert("You painted your " + this.year + " " + this.model + " " + this.color.toString().toUpperCase() + "?!"); }, log: function() { alert("A " + this.color + " " + this.year + " " + this.model) } } }); var theCar = new Car(), theOtherCar = new Car("silver", 2009, "Prius"), theAutomobile = new Automobile("blue"); theCar.log(); // A red 2012 Cooper S theCar.paint("black"); // You painted you 2012 Cooper S BLACK?! theOtherCar.log(); // A silver 2009 Prius alert(theAutomobile.wheels); // 2
Offline
bharvey wrote:
xly wrote:
the result is very slow and quite unusable in practice. I think that the reasons stands in the general bad performance of list handling in Byob.
Yes, we know. And we know how to fix it. It'll certainly happen in 4.0 this summer, and maybe we'll even have time to improve things somewhat in 3.1, but probably not -- only two weeks to go.
But for sure in 4.0; that's the main reason we're doing a complete rewrite!
P..S. I think of all our work so far as just a "proof of concept" and a design exercise. 4.0 will be the first real implementation.
I just wanted to mention that for their day-to-day applications Byobers will probably not yet use the whole theoretical OOP capabilities of upgraded Byob. Nevertheless the new functionalities offer an immense interest for "day-to-day" applications.
On the other hand the main interest of OOP for the software industry is its component-ability (and re-usability). An industrial software application is built similarly to compared to sophisticated electronic devices (think to a PC motherboard) built by assembling off-the-shelf components (look at the dozens of iPad clones already proposed on the marketplace only few months after the original one birth thanks to this componant-ability. Idem for every software application today, games for example).
Even if it is still an issue for Byob, I think that 3.1 upgrade makes progress toward this direction.
Offline
How do I get the blocks to change colors?
Offline
@ bharvey & Jens
OBJECT Allsprites is very convenient. No need to handle the list of sprites by ourself. Allsprites is sorted like the corral if you have re-arranged it, But when the project is re-opened Sprites are re-sorted alphabetically. Up to you to choose sprite names accordingly.
The new SET <anything> TO <value> has a bug. When used inside a script or a block. the fisrt input <anything> is skipped to the second slot and <value> is lost.
Offline