Object-oriented programming in Blockly

[jongseuk lee]

Hello there,

I am Jongseuk from Kaist Korea. I am working on a project that heavily use Blockly as a visual programming language. However I found that Blockly does not work well with an object-oriented design. My initial experiment is that I create a mutable object block and add its properties and methods to variables and procedures category respectively. Thus there will be blocks that similar to 'procedure_callreturn' called 'object_ref' to refer to object's properties and 'object_call' to refer to object's method calls.

I would like to ask if there are any better way to do it or if object-oriented design will be considered in any future release?

Thank you very much.

[Neil Fraser]

We are looking at expanding the type system significantly. The idea
is that the system can determine (with reasonable accuracy) what type
a variable will contain (most of the time). Using this information,
property blocks could be attached to access object properties and
methods.

It can never be foolproof, since we don't want to turn Blockly into
the strictly-typed hell that is Java. But it should be possible to be
pretty accurate.

However, there are a number of more urgent things on our todo list
(dropdown menus, dynamic toolbars, Android, iOS, MSIE). So this won't
be happening (by us) for a while. We'd be happy to see this (or other
approaches) implemented in experiments. You may also be interested in
talking to the App Inventor team. They also use Blockly as their
editor, but they tend to write much larger apps that have objects.
http://appinventor.mit.edu/explore/

> --
> You received this message because you are subscribed to the Google Groups
> "Blockly" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blockly+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Neil Fraser
http://neil.fraser.name

[yoyoyvr]

Any recent thoughts on the type system?

You mentioned not wanting to use strict variable typing, as in Java. An obvious alternative would be the approach of JavaScript itself, in which variables don't have types at all, only data has a type. A variable holds a reference to data of any type. The "type of the variable" is simply the data type of whatever it currently happens to reference. In a sense I guess this is what you've done, with additional (optional) constraints at block layout time.

The current Blockly type system is extremely simple. The Block Factory "Type" category includes four basic types -- number, boolean, string, and list -- and three type constraints -- any, any-of, and other (named constraint).

I think a reasonable approach would be to add another basic type called "object", which would encapsulate the notion of a JavaScript object. This would represent a (loosely) typed data object, basically a set of (key, value) pairs. Perhaps objects could always (or optionally) have a 'typename' field, which could be used to enforce a new type constraint object-of-type.

The trick is to figure out a nice way to create an object with a bunch of named fields, how to set the value of a field, and how to get the value of a field to then be fed as input into other blocks.

This could be done with custom blocks to do things like ...

• create an object from a list of key/value pairs
• create an object by copying another object (should this be a deep or a shallow copy? do we want data inheritance?)
• set the value of a named field
• get the value of a named field
• add a new field?

I can imagine doing this with custom blocks, but it feels like it would be quite clunky without native support. For example, how to enforce type constraints when setting or getting a field?

I would like to be able to define an object type as a data template, defining the default set of initial fields and their default values. I want to give this template a name to be used in type constraints. I would like a simple "object.field" notion for getting and setting fields, to minimize the complexity of object-oriented graphs.

Thoughts? Is anyone working on something in this area?

cheers,

yggy