Op Thu, 2 Jun 2005, schreef Jamie McCracken:
> Daniël Mantione wrote: > > > > Op Thu, 2 Jun 2005, schreef Jamie McCracken: > > > > > >>Daniël Mantione wrote: > > > > > > > Ok! We'll be happy to assist anyone doing interresting developments with > > Free Pascal. Keep in mind though that implementing ideas can take "a lot" > > more time that thinking out ideas. > > > > The Free Pascal parser is indeed manual craftmanship. Some experimenting > > was done using yacc in the past but a handwritten parser turned out to be > > the best choice. The parser units start with the letter p, for example > > pexpr.pas is the expression parser. > > You've done it the hard way - no wonder developer's are reluctant to > implement syntax changes! Depends on your definition of "hard way". The parser is fast and flexible. Ask Carl Eric Codere what the exact problems with Yacc were. But it's "been there, done that, didn't work". > > Yes... Because Java often turns out to be the wrong tool and its memory > > management is one of the reasons. We need to be carefull to prevent Pascal > > becoming a wrong tool. However, automated memory management does have some > > advantages. Nobody can deny that. > > Ref counting does not use more memory! (well okay 32 bits extra to store > the ref count for each object). Yes, but it has its own problems. Think of an object having a reference to itself (think of a ringbuffer with 1 object in the ring or so). Welcome in the real world. Perhaps (likely) there is a solution, perhaps (likely) there are more problems. No expert here. > would become under Rad Pascal: > > uses > Classes, SysUtils; > > TMyObject = class (Tobject) > private > count : integer; > public > constructor create; override; > inherited Create(AnOwner); > inc (count); > > destructor destroy; override; > inherited Destroy; > > > Notice its at least 50% less code to write. Yes. Too bad it is not possible. One of the problems you can expect is with cyclic units. Normally the interfaces of the units form a tree, which define how they get called. So the compiler can compile the interfaces in the depth first order, then it can do the implementations in any order it wants, cyclic uses in implementations are no longer a problem, as the compiler known how to call the procedures in those units. From the good taste department, it breaks the interface/implementation principle. The unit principle guarantees that libraries are being written so that one only needs to look at the interface, not the implementation to know how a library works. It saves a few keystrokes, but makes it a lot harder for the user of the library to understand it. Daniël _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
