[etoys-dev] New vocabularies

[Scott Wallace]

On Mar 6, 2012, at 6:56 AM, Bert Freudenberg wrote:

> I noticed we have many more vocabularies now (see initializeStandardVocabularies). Some where added for this release, some in previous ones.
> 
> However, are we sure they are correctly integrated? When I browse references to the old list types, e.g. TrailStyle, I see they are listed in at least two more places, namely:
> 
> 	ScriptEditorMorphBuilder>>literal:
> 	SymbolListType>>representsAType
> 
> The latter seems to govern the inclusion of a list type in the type menu of a new variable. So shouldn't all new types be listed there? But why are some of the older ones left out, too? And what is the #literal: method about?
> 
> Maybe there should be a single place listing valid user types?

Yes, and let's do it now :)

But what are the types we should offer for user-defined variables?

Right now we offer around fifteen types.  The list, I think, is unnecessarily intimidating, around half of the items surely making most users nervous with their unfamiliarity.  The list of choices in the pop-up includes a few familiar and important ones of widespread applicability, such as Color, Number, Boolean, Sound, and ScriptName -- interspersed among many mostly unfamiliar names such as ButtonPhase, CustomEvents, ImageResolution, TrailStyle and WebCamResolution.

The less common types are typically associated with a parameter of one or two commands and/or variables that occur only in a single kind of morph.  Thus, for example, WebCamResoution is a type that only occurs in a system-defined variable for WebCamMorph objects. and PatchDisplahyMode is only used by KedamaPatchMorphs, etc.

But I suggest that making the narrow-use types available as types for user-defined variables is doing more harm than good, and  I wonder whether it would be better to offer *only* the more-or-less "universal" types.

These might be only:  Boolean, Color, Graphic, Number, Player, ScriptName, Sound, and String -- just those eight.

In practical terms, what would we be losing if we did not offer the "narrow-use types" for user-defined variables?  I wonder whether anyone here knows of any example of use of any type other than the above eight for a user-defined variable.  I believe that in practice the only appearance of the narrow-use-typed variables in scripting has been through use of assignment statements and "watchers" of system-defined variables of the particular kind of object to which they apply.

What we would be gaining by whittling the list of types offered down to something like those eight should be self-evident:  a tractable list which almost every user could expect to be able to intuit the meaning of.
 
BTW Some of the enumerated types have long been intentionally omitted from the type choices offered for user-defined variables, because there has always been a concern about too long a list, and because the types did not apply to any of the kinds of objects that an etoy user would be using, at least not in any practical way.  For example, there are a number of enumerated types that are only found in viewer items for AlignmentMorphs, to govern some table-layout properties, such ListCentering, ListDirection, CellPositioning, CellSpacing.  Luckily, those have never been offered as types for user-defined variables, and now I'm suggesting that we likewise leave out all the other minor types.

Reactions, please!


As to the #literal: method… I'd not seen that before…


> Secondly, we used to avoid camel-casing the items in these list types. However, the new AttachmentEdge type uses e.g. 'topLeft' whereas the old CellPositioning type uses 'top left'. Can we correct this before the new release?

Okay, will do -- sorry I missed that.  In fact the value names get un-camel-cased in the Viewer even if they're declared with camel-case  But the camel-case versions show up in labeled watchers, so it's better to get this changed as you suggest.


> Also, there is a typo, 'bottomRight center' should be 'bottomRight' 'center'.

Right.


Thank you, Bert!

  -- Scott