PDA

View Full Version : Another Visual Basic thread


mdklatt
6/13/2007, 04:15 PM
In a class module, how in the holy hell do you access the private members (shut up, pervs) of another instance of that class???



' class module Timestamp

Private serial as Date

Public Function compare(rhs As Timestamp) As Integer

If (serial < rhs.serial) Then
compare = -1
ElseIf (serial > rhs.serial) Then
compare = 1
Else ' serial == rhs.serial
compare = 0
End If

End Function





Compile error

Method or data member not found



:mad: :mad: :mad:
KABOOKIE
6/13/2007, 04:21 PM
Hey try this.


' class module Timestamp

Private serial as Date

Public Function compare(rhs As Timestamp) As Integer

If (serial < rhs.serial) Then
compare = -1
ElseIf (serial > rhs.serial) Then
compare = 1
ElseIF (serial == rhs.serial) Then
compare = 0
End If

End Function
Petro-Sooner
6/13/2007, 04:22 PM
Looks like Fortran.
Hamhock
6/13/2007, 04:23 PM
you are so stupid.
mdklatt
6/13/2007, 04:24 PM
Looks like Fortran.

Well it ain't, or I wouldn't be having this problem. :(
mdklatt
6/13/2007, 05:50 PM
Come on, I know some of you monkey sacks do the VB all day long....
Vaevictis
6/13/2007, 06:01 PM
I don't know about VB, but in general, in OO programming, you're explicitly prohibited from accessing private members of other objects -- even of the same class.

In other OO languages I've used, they use the "protected" keyword for an object that can be accessed by other instances of the class (and other specified classes). Sometimes it's limited to subclasses only though.

You might want to look into "friend" also.
mdklatt
6/13/2007, 06:12 PM
I don't know about VB, but in general, in OO programming, you're explicitly prohibited from accessing private members of other objects -- even of the same class.

Not in C++...and why should you be? Presumably, a class module doesn't need to be protected from the inner workings of itself. :confused:



In other OO languages I've used, they use the "protected" keyword for an object that can be accessed by other instances of the class (and other specified classes).

VB has the "Friend" declaration, but there are a couple of things wrong with it. First of all, it applies to the entire "project"; you can't specify individual modules. Even more unacceptable in my case, it only applies to procedures, not variables. :confused: :mad:
Vaevictis
6/13/2007, 07:03 PM
Not in C++...and why should you be? Presumably, a class module doesn't need to be protected from the inner workings of itself. :confused:

Well, the way it was explained to me was that in theory, ideally you don't want even other instances of the class munging in the internals of a specific object. Theoretically, you want to force them to go through a public/protected/etc interface which you have defined.

(This attitude is apparently inherited from "Smalltalk", which is considered to be the canonical OO language -- apparently, nobody outside of an object could directly access an objects internal state, they had to "message" the object to get the object to change its own internal state...)

In any case, C++ doing it is why I said, "in general." Individual languages will bastardize... er, I mean, make trade offs as they see fit. :D


VB has the "Friend" declaration, but there are a couple of things wrong with it. First of all, it applies to the entire "project"; you can't specify individual modules. Even more unacceptable in my case, it only applies to procedures, not variables. :confused: :mad:

Define a public and/or protected procedure then?