getters/setters

[James C. Fuller]

Charles,
  From the other forum you posted this code for getter/setters. which does work
'==============================================================================

Code Select Expand


class GetSetter
  int    v_1
  string v_2
  int    v1()         {return v_1}
  sub    v1(int v)    {v_1=v}
  string v2()         {return v_2}
  sub    v2(string v) {v_2=v}
end class
'#recordof getSetter
'TEST
GetSetter g
g.v1=42
print g.v1 '42'

'==============================================================================
but this does not.
'==============================================================================

Code Select Expand


use rtl64
#autodim off
use console
use corewin
'==============================================================================
class GetSetter
  int    v_1
  string v_2
  int    v1()         {return v_1}
  sub    v1(int v)    {v_1=v}
  string v2()         {return v_2}
  sub    v2(string v) {v_2=v}
end class
'==============================================================================
Function main() As sys
    GetSetter g
    g.v1=42
    print g.v1 cr '42'
wait
End Function
main


James

[Charles Pegge]

Hi James,

Brackets are needed to prevent cr being treated as a param of g.v1
print g.v1() cr '42'

Code Select Expand


...
Function main() As sys
    GetSetter g
    g.v1 42
    print g.v1() cr '42'
wait
End Function


[James C. Fuller]

Charles,
  Ok.
Now a real issue I think
You should not be able to access private variables
James

Code Select Expand


use rtl64
#autodim off
use console
use corewin
'==============================================================================
class GetSetter
    private
          int    v_1
          string v_2
    public   
          int    v1()         {return v_1}
          sub    v1(int v)    {v_1=v}
          string v2()         {return v_2}
          sub    v2(string v) {v_2=v}
end class
'==============================================================================
Function main() As sys
    GetSetter g
    g.v1=42
    print g.v1() cr

    'you should not be able to do this with v_1 private
    g.v_1 = 47
    print g.v_1() cr
wait
End Function
main


[Charles Pegge]

Ah yes, I removed the public / protected / private constraints from O2, a while back, so these are notional only, and assume that programmers do not need to be nanny'ed in managing their own encapsulations.

On the other hand, all class static variables are structurally private, and can only be accessed when exposed via a method.

[James C. Fuller]

Charles,
   What if I want/need private Methods?

James

[Charles Pegge]

It depends on what level of privacy you require. So-called private members are so easy to hack, it's not worth using symbolic constraints other than 'please keep off the grass'.

For true privacy, you would need to provide a virtual interface of some kind.

[Mike Lobanovsky]

So-called private members are so easy to hack...

Oh?

Charles, I am very much eager to be shown how I would be able to access a private member of a PB/VB/C++/.NET/Java class from the outside of that class code, especially in a 3rd party module and at run time.

No, I am not an Anonymous, or script kiddie, or luser, but rather a plain old hacker of sorts.

[Charles Pegge]

Hi Mike,

You can overlay the Object with your own, fully public structure. The virtual functions table address is the first, though undeclared, member of the object.

The virtual functions table is a contiguous array of all the function pointers, including the private ones.

C++ and COM objects follow this layout, and so do o2 extern objects.


Is that good enough for an old hacker, Mike

[Mike Lobanovsky]

Is that good enough for an old hacker, Mike

Not quite, Charles.

While it may be true for Java classes (and I wonder why), it is certainly not so for C++. IIRC the C++ standard does not even mention vtables as standardized items, so, unlike interfaces, vtable structure and implementation are entirely compiler-dependent. You can create a compiler with multiple vtables that will be comprised entirely of public and possibly protected/friend props and methods, and separately, of private ones – and still remain C++ standard-compatible. Classic VB(6) uses a C(++) compiler to generate "native code" executables and thus falls into the same category as well. I am not sure if the .NET and PB compilers would follow a different logic or standard.

In other words, if the compiler is not your own creation, you will have to first hack the compiler to find out where and how it stores the object's vtable(s) and what each one of them is for. And then you will have to hack your own compiler (possibly with bogus headers) to make it believe it's going to access genuinely public, not private or protected, props and methods. If it were not so then there wouldn't be any sense in re-inventing the wheel (classes) while you could still implement the exact same behavior using ordinary C structures with "callable" member fields.

But thanks for the answer anyway. It helps understand your way of technical thinking better.

[Charles Pegge]

Thanks, Mike.

I should add that O2 also has its own internal implementation of objects. The virtual function table pointer is absent from the body of the object. And the function table is an array of sys variables called myclass_table, and a method call will use it directly. This is much cleaner for handling multiple inheritance.

However, since I am not in favour of prohibitions, I thought it would be a good idea to save hackers the trouble. Occasionally, it helps to inspect private variables when debugging.

I understand that only virtual / pure / com objects are supported by all C++ compilers, in the standard format.

[Mike Lobanovsky]

Thank you on behalf of the hackers, Charles. Your information is very helpful, as always.