Hi, Pauli seems to be heading the same way I am, locking all things into classes. With regards to global variables, I've started to create a configuration class for my apps. This has the added benefit that I can save the program configuration with changes to a config file in one clean location.
Being an assembler programmer, pointers don't bother me too much, but I must admit I prefer dynamic arrays in Delphi, it just makes the code clearer and it doesn't appear to have much impact on performance. Having said that, I have a few GIS apps where I use pointers heavily as class overheads are a bit too much and dynamic arrays are a bit messy. Even there, I've started exploring ways of using arrays within arrays of records. Peter kevin wrote: > ----- Original Message ----- > From: "Paule Ecimovic" <[EMAIL PROTECTED]> > To: "Borland's Delphi Discussion List" <[email protected]> > Sent: Monday, April 24, 2006 2:08 AM > Subject: Re: Delphi and Java > > > >> Hi, Kevin and All >> >> Your comment about using instance variables as 'pointers' raises an >> interesting question of how object oriented programming has conceptually >> replaced pointers. A transition from a pointer-intensive language like C, >> where pointers are used compulsively even if they are not necessary, to an >> object-oriented language such as C++, Delphi or more restrictively Java. >> Where have all those pointers gone ? :-) and how do object-oriented >> languages design-pattern them out of explicit code all together? >> > > The more I have been using a heavily OO approach, the less I have been using > pointers explicitly (I practically never use the Tpointer declaration); > however Delphi instance variables > are really pointers to assigned memory (Student.Course.Coursename is a > pointer to a pointer to a pointer to a string) > The use of namespaces and structs in C# (simple variables are not declared > as 'free' variables but > part of an object structure) favour or even impose an OO approach; > (I find it more ordered and intelligible: C was famous for causing ambiguity > with its use of pointers, > I have also seen globally declared variables in Delphi cause havoc due to > having several of them declared with > the same name but in different modules; I have also seen similar problems > caused by calling > the create method of a given variable several times, or by assigning its > owner to Nil); > In Delphi, in practice I pack all variables into classes or else declare > them locally within methods, > the only exception being global constants, though I am tending to pack them > into classes or records too: > > var global_consts : > record > aa : integer; > bb : integer; > end; > > implementation > begin > global_consts .aa = 12;//assign default value > global_consts .bb = 13; > end; > > I prefer to use 'global_consts.aa' instead of just 'aa' > because you know what you are referencing (you could have multiples > instances of 'aa') > > > Typecasting is useful too in dereferencing objectlists, which I often use > for lists of custom object instances: > > Type TCourseObjList;: TObjectList; (contains methods for adding/deleting > intances of TCourse) > > var Courses: TCourseObjList; > > var CurrentCourse: TCourse; > > CurrentCourse:= TCourse(Courses[xx]);//xx is course index number > > This type of structure is good if a single Student is assigned to multiple > courses (TCourseObjList) > of undetermined number (the TCourseObjList is dynamic); > > The advantage of having the TCourseObjList component is that it has its own > methods for internally creating > the TCourse instances and adding them to the list, assigning default values > etc. Once it is tested and functional, > it is used by declaring an instance and using its methods and dereferencing > it: there is little scope for mistakes with pointers > (@CurrentCourse, CurrentCourse, CurrentCourse^ etc) and the possibility of > using Nil pointers by mistake is reduced; > > These propositions work well in Delphi and C#, so I presume also in Java and > other OO languages; > > Kevin > > _______________________________________________ > Delphi mailing list -> [email protected] > http://www.elists.org/mailman/listinfo/delphi > > > > _______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
