[PataPata-discuss] Progress on library support and short-term plans

[Paul D. F. <pdf...@ku...>]

I've finally completed the changes to alow nestied world to be used as 
support libraries and put it into SVN. It would not surprise me if there 
remain bugs with the work as I made some major changes. I will continue to 
test it as I move on to more GUI oriented things now. The results are 
mostly behind the scenes; you would mainly only notice it on saving a file 
and looking at the results (which are shorter).

If you've read any of my long posts such as to edusig you might think I'm 
a wordy guy, and you would be right :-), but when it comes to writing 
code, I definitely try to be as concise and compact as possible (and that 
includes even the output of tools I write that write code. :-) In this 
case, what was (hopefully) accomplished is that the example world for TK 
now depends on another world (as the moment, "CommonPrototypesTK.py", 
though that file name may change).

So, the WorldExampleTK.py file has now shrunk from 32K to 5K. Now, if I 
was getting paid per line, I guess I would have to give money back :-) But 
as I am of a philosophy that think more of "lines of code expended" as 
opposed to "lines of code created", less is more. :-)

Much of the code moved into CommonPrototypesTK.py (14K), and some into 
inspectorTK_v111.py (12K). So, ignoring the inspector code, it is more 
like the example world size shrunk from 19K (14K+5K) to 5K (the rest being 
the inspector, which also shrunk from 42K to 12K, as it otherwise has a 
copy of all the library code in it to do tk widgets).

Anyway, overall, before the refactoring, it would have been about 32K for 
the example world, and 42K for the inspector, or 76K total, but now it is 
31K total. I.m not much concerned with saving on the disk space or memory 
use; I'm mainly trying to help the end user manage the complexity of all 
this. So, that is less code to have to worry about looking at when you are 
building your own window (5K vs. much more).

In general, I think the biggest issue with a computer language is 
"documenting intent" and the biggest issue with a programming tool is 
"managing complexity". There are other important things with languages or 
tools, but I think those are the biggest issues long term. So, this 
refactoring work falls in the category of reducing complexity of world 
(which also indirectly aids in understanding the intent of the developer).

I still need to put in place a way to save any changes to the library you 
make while it is open in the main world; right now you would have to open 
a library directly as a main world and change it. It also does not warn 
you if you modify library code (which will not be saved) in a main world's 
inspector.

Anyway, this all might sound pretty confusing, and does add another layer 
of complexity, but if you think of worlds as somewhat like python modules, 
then this would make more sense (and modules are one of Python's best 
features). So,rather than do an "import CommonPrototypesTK" you do a:

world.worldLibraries =
          [Prototype.loadWorldFromFile("CommonPrototypesTK.py")]

I actually wanted to make worlds be the same as Python module objects, but 
I can't quite figure out a good way to do that.

Tops on my list to do next are supporting nested morphs and beyond that 
adding sizing panels (e.g. spacing evenly left to right, top to bottom, 
placing around borders, etc.), so, for example, the inspector would resize 
with the window. There are a few ways to do this, so I'm not sure what 
approach I will take yet. After that, then there is more to do in the 
direction of HyperCard-like support, including perhaps porting over the 
PythonCard demos (but in a PataPata way). But, before I ported too many 
PythonCard apps, I would be tempted to do a bit more trying to make as 
much of the PataPata system platform-independent as I could easily.

There is a "todo.txt" file in SVN with some more details on plans and 
priorities.

--Paul Fernhout