The pointers are still there, they're just hidden by the compiler. The
Delphi designers observed that because pointers were an inherent part of
object oriented programming in that you need a pointer to manage a
dynamically created object, that rather than force programmers to constantly
dereference a pointer as in pObject^.SomeField that they would just do it
implicitly for us (one of the gifts of Delphi). And of course your still
perfectly allowed to use pointers in your OOP or procedural Delphi code as
in:
TMyClassPtr = ^TMyClass;
TMyClass
property Color: TColor;
end;
pMyClass: TMyClassPtr;
New(pMyClass);
pMyClass^.Color := clRed;
Scott Kellish
----- Original Message -----
From: "Paule Ecimovic" <[EMAIL PROTECTED]>
To: "Borland's Delphi Discussion List" <[email protected]>
Sent: Monday, April 24, 2006 5: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?
>
> All the best,
>
> Paule
> ----- Original Message -----
> From: "kevin" <[EMAIL PROTECTED]>
> To: "Borland's Delphi Discussion List" <[email protected]>
> Sent: Monday, April 24, 2006 12:33 AM
> Subject: Re: Delphi and Java
>
>
>>
>> ----- Original Message -----
>> From: "Alan Colburn" <[EMAIL PROTECTED]>
>> To: "Borland's Delphi Discussion List" <[email protected]>
>> Sent: Friday, April 21, 2006 11:27 AM
>> Subject: Re: Delphi and Java
>>
>>
>>> The difficulties come when I try to apply the ideas to real world
>>> situations. First, it seems like there's a lot of applications that are
>>> simpler to write in a more procedural style, e.g., general utility or
>>> office-like apps for individual users, like a text editor, mp3 player,
>>> or
>>> file utility program.
>>
>>> Second, even when trying to create something that
>>> *does* fit well (even to me) within an object oriented viewpoint, it's
>> hard
>>> for me to figure out where best to place methods, and how to have
>>> objects
>>> communicate with one another. For example, if one were writing an
>>> application related to managing students registering for courses, it
>>> makes
>>> sense to have Student objects and Course objects. When one registers,
>>> though, these objects would need to communicate with each other. I would
>>> have trouble deciding how to do that, while keeping classes/objects
>>> "encapsulated," and deciding where to place a Register method--after
>>> all,
>>> registration affects *both* the Student and the Course.
>>
>> One technique I often use in a custom class is to put a 'pointer' or
>> instance variable to another custom class:
>>
>> eg.
>> tCourse = class(tcomponent)
>> public
>> CourseName: string;
>> //course specific variables/methods etc.
>> end;
>>
>> tStudent = class(tcomponent)
>> public
>> Course : tcourse;
>> procedure Register(CourseName: string);
>> //student specific variables/methods etc.
>> end;
>>
>> var Student: tStudent;
>>
>> The Register method in tStudent could be used to assign the value of
>> CourseName
>> which may then be referenced as Student.Course.CourseName
>>
>> An instance, Student, of tStudent has to create an instance of Course in
>> its
>> constructor
>> (so that Course has assigned memory and is not NULL),
>> but then all the methods of tCourse are already available within the
>> tStudent
>> object;
>>
>> It's possible to create hierarchies of components like this, each having
>> other
>> components nested internally;
>> Using procedural methods only (without objects), such structures
>> would be difficult to emulate;
>>
>>> So, for now, I'm taking a look at Beginning Java Objects. Even though
>> "Java"
>>> is in the title--hence my previous question--much of the book is about
>>> the
>>> general ideas, with little or no connection to Java itself. I think the
>> book
>>> devotes a lot of attention to the issue I just mentioned.
>>
>> The basic ideas of OOP are pretty general;
>>
>>> Again, I appreciate the responses and the reading suggestions. I'm not a
>>> programmer (yet!), but I am an educator, and I know that the teaching
>>> resources available today for Java (beginners) are definitely superior
>>> to
>>> those available for Delphi (and probably most other languages, too). So,
>> I'm
>>> glad folks sent along a couple of the older resources for Delphi that
>>> they
>>> thought were both useful and still up to date enough to be valuable.
>>
>> It's true that there is a lot of stuff on Java and its widely used,
>> but I have to say that I prefer to work in Delphi;
>> I am moving to Java/C# in order to have work,
>> not because I particularly want to;
>> (In Italy Delphi is not very widespread)
>> C# is also well constructed as far as OOP is concerned and is close to
>> Java;
>>
>> _______________________________________________
>> Delphi mailing list -> [email protected]
>> http://www.elists.org/mailman/listinfo/delphi
>>
>
>
> _______________________________________________
> Delphi mailing list -> [email protected]
> http://www.elists.org/mailman/listinfo/delphi
>
CONFIDENTIALITY NOTICE: The information in this message is confidential and
may be legally privileged. It is intended solely for the addressee. Access
to this message by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying, or distribution of this message, or any
action or omission taken by you in reliance on it, is prohibited and may be
unlawful. Please immediately contact the sender if you have received this
message in error and permanently delete this message and any attachments.
Thank you.
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
