Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!wuarchive!decwrl!shelby!helens!calvin!rudd
From: rudd@calvin.tmc.edu (Kevin Rudd)
Newsgroups: comp.sys.mac.hypercard
Subject: Re: New feature for 2.1 wanted
Keywords: by users in the current versions of HC.  Apple
		   is not able to merge this capability in with the
		   current user interface.
Message-ID: <1112@helens.Stanford.EDU>
Date: 9 Oct 90 02:22:44 GMT
References: <2106@gazette.bcm.tmc.edu> <21064@well.sf.ca.us> <10614@goofy.Apple.COM>
Sender: news@helens.Stanford.EDU
Reply-To: rudd@calvin.UUCP (Kevin Rudd)
Organization: Stanford University
Lines: 46

There are a number of different ways of referring to sub-elements of
different systems.  Fortran uses (coords), Pascal and C use [coords],
etc.  One could use any kind of delimeters to provide this functionality
without violating the spirit of HC.  foo.x.y might work as might
the addition of row x column y of foo.  Since matrices and such are
different types of objects, they must be "similar" to other types, not
"exactly the same as".  For example, buttons and text fields are different.
One cannot say:  word 3 of line 5 of card button foo.  It just doesn't work.
By the Apple/Claris response I would expect that buttons and fields will
either be consolidated or one will lose out to the other to maintain
the "consistent user interface".

Understand that the "consistent user interface" is the one thing that sets
the mac apart from other machines---PC's and workstations alike.  However,
there is no reason to release crippled software solely for the sake
of a "consistent user interface".  Does MacWrite obey the EXACT commands
of Hypercard?  Or the Finder?  None of these things are identical.  For that
matter, will a HC 2.0 stack work on HC 1.5?  HC 1.0?  If the "consistent
user interface" were really a requirement, no new features would ever be
seen as compatability must be maintained.  Only bug fixes and performance
enhancements would need to be considered.

Of course, the previous paragraph is really not the case.  New versions
almost always have new (and sometimes different) features.  Hence the
creation of the Mac line.  The Mac II line.  Otherwise we'd all be sitting
behind increadibly fast (but dumb) Apple I computers.  By adding a new
field type of "Data" or "Matrix" or "Array" to "Button" and "Text" HC would
be vastly increasing the capability of users to generate applications.
Consider the common application called a "Calendar".  This is kluged beyond
belief in the Apple Distribution of HC.  The problem would have been trivial
for the programmer had s/he had a grid instead of an assembly of fields.

Please, Apple.  Do not be blind to progress for the sake of 100% stability.
And don't plead compatability on some items and then change the rules
on other items.  Neither is a good way to be.  Support your users --- the
ones who buy your computers and pay your saleries and dividends.  Remember,
if Apple doesn't support the customers, either someone else will or there
won't be customers.  In either case, Apple loses.

Custom statement and disclaimer:  I don't use HC.  One of the major reasons
is that it is impossible to set up fields with more than 0 dimensions.  Many
of the applications which HC begs to solve REQUIRE this capability.  Otherwise
HC is only a flat image/text linked system good for games like Cosmic Osmo
and imitations of simple 3x5 cards.

  -- Kevin.