Re: [Ctool-develop] little fixes

[Shaun F. <fli...@so...>]

Steven,

It sounds to me like we're basically in agreement here.  My plan going 
forward is to, for example, take the time to add accessors to all 
classes I work on, without making the members private.  So, the old API 
continues to work while a better one is available.

Yes, I've been a bit short on time and the necessary motivation lately 
to do cleanup like this.  I was also having some difficultly with the 
early (Mac) versions of gcc 3.0 that led me to spend more time on my 
Metreowerks-using projects. :^)

I think the next thing needing doing has to be improved handling of gcc 
extensions, which is what I was working on during my last major ctool 
development push.  Not being able to cleanly use standard include files 
is quite the bummer.

Thanks,
Shaun


On Friday, August 1, 2003, at 12:03  PM, Steven Singer wrote:

> Shaun Flisakowski wrote:
> > I'm glad to hear that.  I lost a few users in the switch, some just
> > stuck with their CTree code, one person said they wouldn't use it now
> > that it could no longer parse itself.
>
> I can imagine that if you're trying to write a compiler then it's
> important that it be able to compile itself.
>
> My old code written with CTree I've left alone. After all, it works
> so there's no need to break it.
>
> > I agree, but as I mentioned I think API changes need to come in 
> phases;
> > with a plan that allows for slow migration among the user base - I'm 
> not
> > looking to make any new enemies, I'm full up.
>
> I agree. Pissing people off is not a good plan.
>
> However, slowly migrating an API is probably not the best solution.
> The people who are using the old API will complain as soon as it moves
> at all, the people who want a new API will complain that things aren't
> moving quickly enough and everybody else will be coding to a moving
> target.
>
> Probably a better approach is to take some time to decide on a new,
> clean, API - the one you would have had if you'd started from scratch
> knowing all you do now. Then, make the new API available as a wrapper
> to the existing API. This would allow existing users to keep using the
> old API and new users to immediately write to the new API. The old API
> could initially be marked as deprecated but still available.
>
> Then, only as internal changes rendered the old API invalid would
> people be forced to move.
>
> This method has the advantage of delaying pissing people off until
> absolutely necessary and also providing a nice clean API not
> compromised by legacy interfaces.
>
> Another approach would be to have a new set of data structures with
> a new API and provide import and export facilities to the old data
> structures. New features need be added only to the new data
> structures but people could avoid the conversion step if they relied
> on implementation details of the old structures.
>
> However, this is a big job and should only be undertaken if the
> resources are available to see it through to the end. Since I'm not
> offering you any of my time, feel free to tell me to go away.
>
> 	- Steven
> -- 
>
>
>
>
> **********************************************************************
> The information transmitted is intended only for the person or
> entity to which it is addressed and may contain confidential and/or 
> privileged material. Any review, retransmission, dissemination or 
> other use of, or
> taking of any action in reliance upon, this information by persons or 
> entities other than the intended recipient is prohibited.  If you 
> received this in error, please contact the sender and delete the 
> material from any computer.
> **********************************************************************
>