Re: [Ctool-develop] little fixes

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

On Thursday, July 31, 2003, at 02:44  PM, Steven Singer wrote:

> Shaun Flisakowski wrote:
>> As for your comment about vectors, cTool was originally written in C 
>> (as the poorly named "CTree", which I now know is also a database 
>> product).  With version 2.0, I changed over to C++ so a class 
>> hierarchy could be used to clean up the resulting AST - I was not 
>> looking to rewrite from scratch using C++.
>
> I know about CTree. I've used that too.
>
> CTool is a huge improvement in usability over CTree, the interfaces are
> much cleaner. The latest program I tried to write I started with CTree
> because that's what I had handy and got into a real mess. When I
> changed to CTool, all the complexities disappeared and I could spend
> my time concentrating on deciding what I wanted to do instead of how to
> do it.

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.

> However, CTool is still showing its C roots. Too much of the internal
> workings of the data structure are exposed. This makes it very
> difficult to change any detail of the implementation.

While I agree these things should be hidden, I'd want to do that very 
slowly - I'd be loathe to break people's existing solutions.  The first 
step would have to be accessors for all the classes, then after a few 
more releases pass by, start making the members private.  Where I work, 
we have a define:
	#define	privileged		public

that we use to indicate this is the direction this class (which was 
once C, which was once pascal) is headed.

My preference would be change a particular implementation as needed (to 
be vector or list), perhaps making it private at that point.  This way, 
only users modifying that particular item would be affected.

> For example, suppose I had needed a fast insertBefore method. This
> would have required updating the Statement data structure to be
> doubly linked. Since the next pointers are exposed, I'd have no control
> over what external code is using them to manipulate the data structure.
> If the manipulation did not take into account the new pointers I would
> have needed to add, then the result would have been a complete mess.
>
> Hiding all the implementation details will allow future changes to
> the internal workings. At the moment you don't even have to change
> the implementation, just hide all the variables and work out what
> actions are needed on the objects.
>
> Hiding the variables, however, will break any existing program that
> relies on the current implementation. It would have to be reserved
> for the next major version.

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.

> Do you have a good idea what sort of tools people are building with
> CTool amd hence what manipulation options they need?
>
> 	- Steven
> -- 

At the point I switched over to using sourceforge, there were about 50 
people on my mailing list.  Of the ones that asked me questions, many 
were graduate students using ctool in some project.  These are the 
low-end solutions, consisting of: parse, modify AST, and print modified 
output.  One example that comes to mind was someone inserting a 
function call at the beginning of each for/while loop block.

High-end use is using ctool as a front-end to your own compiler (for 
some embedded system, etc).  For example, Cisco was using ctool in 
their testing dept to do something or other. I went over to the company 
(a few blocks from where I work) to talk to them about it.  I met with 
a group of people, one who had already used ctool in a prototype of 
some new testing system - the specifics are their business alone, but 
they were willing to sink some serious resources into their project.  
Assuming they currently have 100K LOC or more in their project, I would 
imagine some unhappiness with a large change to the API unless backward 
compatibility is kept in mind.

Thanks,
Shaun