Why we should remove {} from Squeak

danielv at netvision.net.il danielv at netvision.net.il
Mon Oct 1 22:30:21 UTC 2001


How about this -

self premadeFlowFormula forParameters: ...

#premadeFlowFormula is an accessor to a cached object representing a
mathematical expression.

The browser tool recognizes the "premade" prefix, which is a convention
for such things. So it looks for and finds a method called
flowFormulaDefinition, which returns an XML description (in this case,
probably MathML) of the formula. It is this method that would be used
for the lazy initialization of the formula object.

Having found the conventional matching "Definition" method, having
recognized it as standard XML, it checks the schema for the data, and
starts looking for the appropriate object to represent it directly in
the method. This could be an inline editor, or an icon that brings one
up. If this object is used in more than one place (other accessors to
the sender), the browser gives some indication of the further
implication changing it might have.

Of course, this works for math, SVG graphics, icons, whatever.

No syntax changes, your code can be published anywhere and be completely
readable by standard tools, but you get most of the advantages of
Jecel's powerful "just put the objects in the code" usage metaphor.

The convention can serve eToys just as easily as textual browsing tools.

Of course, the browser should provide convinient tools for embedding the
things in the first place, automating the creation of the accessor, lazy
initalization (if caching is wanted) and so forth.

Daniel

"Stephen Pair" <spair at advantive.com> wrote:
> Andreas Raab wrote:
> > > Having operators is useful too, I would like to have operators too 
> > > because I prefer to type
> > >    2 + 3 * 6 than 2 + (3 * 6)
> > > and because this is MATH and MATH are right!
> > >
> > > I hope you see my point.
> > 
> > If your point is that we should not have appropriate operator 
> > precedences, then I don't see it. I find absolutely nothing 
> > wrong with them. There are plenty of language (Prolog, for 
> > example) dealing with operator precedence pretty well and at 
> > the same time not restricting people to use only built-in 
> > operators. So actually I agree - I want operator precedences too! ;-)
> 
> I think we should be careful on this slippery slope...as you point out,
> there is a delicate balance between simplicity and purity.  Many
> languages have been ruined by adding constructs that were meant to make
> things more convenient but sacrificed consistency.  I think this was
> Stephane's point actually.  These constructs usually make a language
> more convenient for those with a lot of experience in the language, but
> much more difficult for people new to the language.  If you need proof
> of this, just look at the recent thread titled "Storing and Retrieving
> Points."
> 
> I'm not arguing against using mathematical precedence, just that the
> idea be carefully considered.  Also, there are many mathematical
> expressions that cannot be rendered in plain text.  Why not augment
> Squeak with the complete language of mathematics instead?  Let's allow a
> mathematical expression to be constructed using a full graphical
> representation and then be dropped into a method.
> 
> - Stephen




More information about the Squeak-dev mailing list