Hi, Kevin and all,
Thanks for your wide-ranging responces to this nagging perennial
question, which crops up a every turn in bringing old code "up to (the new
building) code".
Shielding (application) programmers from pointers by enabling run-time
instantiation of objects "anywhere" in main blocks of code, while retaining
their use behind the scenes seems to go hand-in-hand with the abstraction
increase introduced by abstract data types. Purely-object oriented langauges
leave it at that, whereas mixed-model hybrid languages allow for various
degrees of explicit pointer manipulation for all
sufficiently-"bloody-minded"-programmers whose insist on mid-level control.
Were it an issue of performance, I guess the most frequently run code would
be hand-coded assembler patched into a host higher-level language for
structural convenience, which is a dying art but retained only by OEM
programmers and game hackers. JIT Compiler technology advancement is,
granted, reducing the need for this at the cost of monitoring overheads.
]More specific code question to follow.
Thanks,
Paule
----- Original Message -----
From: "kevin" <[EMAIL PROTECTED]>
To: "Borland's Delphi Discussion List" <[email protected]>
Sent: Tuesday, April 25, 2006 3:13 AM
Subject: Re: Delphi and Java
>
> ----- 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
