To: dougo@ccs.neu.edu, lieber@ccs.neu.edu
Subject: Re: name change
Cc: Pengcheng, johan

Hi Doug:

>From dougo@ccs.neu.edu  Thu Sep 14 19:35:09 2000
>From: Doug Orleans <dougo@ccs.neu.edu>
>Date: Thu, 14 Sep 2000 19:35:07 -0400 (EDT)
>To: Karl Lieberherr <lieber@ccs.neu.edu>
>Subject: Re: name change
>
>Karl Lieberherr writes:
> > Hi Doug:
> > 
> > /course/com3362/sp99/DJ/simple-example
> > 
> > My students might be confused by the name changes to the parts:
> > 
> > b -> fb
> > etc.
> > 
> > Is this documented somewhere. If not, I need to explain it in class.
> > Please can you provide the rationale again.
>
>I don't think it's documented yet.  The rationale was (this was Josh's 
>decision) to avoid name clashes between fields and methods with the
>same name.  This wouldn't be a problem, though, if accessor methods
>are always named getFoo (or get_foo).  Do you think I should remove
>this, and just report an error if you try to add a field and a method
>with the same name, or do you have an alternate idea for notation?
>The only way the user interacts with edge names is in "bypassing"
>constraints, so we might be able to just adjust the edge-glob notation 
>somehow.
>

It seems to me that your suggestion of reporting an error is the right
solution. It is unlikely and bad practice anyway to have a field
and a method with the same name. This is indeed a minor restriction.
Then the bypassing can use the part names from the cd.

Is this a big change for you?

-- Karl