[kepler-dev] [Bug 1845] - user input for port type should not be case sensitive

[bugzilla-daemon@ecoinformatics.org]

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=1845

cxh at eecs.berkeley.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |ASSIGNED



------- Additional Comments From cxh at eecs.berkeley.edu  2005-12-19 10:47 -------
Shawn wrote:
> What about Boolean ?
Boolean is sort of a proper name (http://en.wikipedia.org/wiki/Boole)
and it should be capitalized.  However, the Java primitive type is "boolean"
and the corresponding wrapper class is "Boolean".  In Ptolemy, the type
is "boolean" so as to match the other types.  This could be a mistake,
and perhaps PtParser should be modified, but I'm probably not going to do it.

The way the combobox gets its types is by calling data.expr.Constant.types()
which returns the TreeMap of types.  Thus, all the basic types in the lattice
should be present in the combobox.

Laura writes:
> 1.  when first tested, the user had to exactly type something in for the 
> system to recognize it.  That is way too much burden on the user.  I very much 
> doubt there are many users that really want to assign string and STRING to be 
> two different types! :-)

Agreed.  However, there can be problems with having multiple representations
of the same thing.  I think what we have now will work for the fundamental
types.  The question is, should the parser be modified to be case insensitive
about nonfundamental types like arrays, matrices and records?
If I type STRING into the combo box, then the it will change to string.
However, if I type [STRING] it will not change and I'll get an error.
To change this requires modifying the parser either be introducing aliases
(String, string, STRING) or trying to make the comparison case insensitive.

> 2.  the second issue is that a set of common data types should be offered to 
> the user so they don't have to type at all if they are choosing a standard 
> type.

We've had combo box in the Port Configuration dialog for some time.  I
think I updated another bug about it, but failed to update this one.
This change is present in alpha8, so give it a try and let me know what
you think.  I realize that the "Configure Ports" dialog is not at all what
the Kepler group wants, but I'm trying to push bugs along that require Ptolemy
backend work so that we move closer to the final set of Kepler dialogs.

> 3.  it should really be a combo box so a user can indeed add/specify a type 
> that is not part of the standard set (I can't remember where but I wrote a bug 
> that talked about using combo boxes where possible in whatever situation we 
> had that there was generally a standard set of choices but also allows for 
> customization by the user.  And if a user created a new type for example 
> called String, then for that user String should subsequently show up as a 
> choice.  We could also consider allowing users to "globally" add new types so 
> they are available for other users.)

Right now, we rely in the _type TreeMap in the Constant class to be updated.
So, if adding a type updates _type, then the combobox will see it as a choice.
If the user creates a type called "String", and the parser recognizes it,
then it will not be automatically converted to "string".  The reason is that
we only try to fix things if the isValid(String value) method fails.
Currently, isValid() passes value to the parser, so it is up to the parser
to do the right thing.
 
Adding user types is another issue and should probably be a separate bug and
won't be addressed here.
Right now, to add a type requires modifying the Ptolemy code.