[Gambas-user] Interpreter's treatment of classes

[Bruno Félix Rezende Ribeiro]

Em Sat, 12 Apr 2014 17:38:03 +0200
Benoît Minisini <gambas at ...1...> escreveu:

> All that is because, "is a" has two meanings in Gambas.
> 
> 1) An object reference A "is a" class B. It means that the class of
> the object A is the class B.
> 
> 2) An expression "is a" datatype. And there are two datatypes, 
> "gb.Object" and "gb.Class".
> 
> "gb.Object" is any expression that returns a non-null object
> reference. An object reference internally includes two pointers: a
> class pointer, and an object data pointer.
> 
> "gb.Class" is any expression that returns a class. It includes one 
> pointer, the class pointer.
> 
> "gb.Class" exists only for internal optimization reasons. I could
> have used instead a "gb.Object", with a null object data pointer. But
> it would have been slower.
> 
> Now, as stated in the wiki, classes are really objects whose class is 
> the "Class" class. But a reference to a class as an object is not the 
> same thing as a reference to the class. The first one has methods
> that describe the class structure, the second one allows to call the
> static methods of the class.
 
I think I can see what you mean here.  But I can't quite understand how
have you reached the conclusion that "classes are really objects whose
class is the 'Class' class"?  What is the criteria classes are
satisfying that

1) Makes them objects.

2) Granted (1), makes them instances of the class "Class".

Are the answers to these two questions consistent with the Gambas'
meaning of "object", "class" and "instance"?  Or is that just a
particular exception to the general rule?

Do you see any problem with the perhaps more intuitive and consistent
approach of making 'Class' a primitive type as explained in the model
below?


** Reformulation of the interpreter's behavior regarding classes **

The declaration

  Dim hClass As Class = MMain

would make 'hClass' point to the same class that 'MMain' points to
so that

  TypeOf(MMain) ==> gb.Class
  TypeOf(hClass) ==> gb.Class
  If(hClass = MMain, "Equal", "Not Equal") ==> "Equal"
  MMain Is Class ==> [Error: Unexpected Class]
  hClass Is Class ==> [Error: Unexpected Class]

The errors are the same current raised by the expression

  MMain Is Integer ==> [Error: Expected Integer]

This is consistent because like the type 'Integer', the type 'Class'
would be not a class, and therefore would not make sense as the
right-hand side operand of the 'Is' operator which is intended to check
instantiation regarding inheritance, which is clearly not applicable to
classes in the reformulated model.

On the other hand to obtain the introspection capabilities the
declaration

  Dim hClassIntrospection As ClassInstropection = MMain

would make 'hClassIntrospection' points to the object which describes
the class 'MMain' so that

  TypeOf(hClassIntrospection) ==> gb.Object
  hClassIntrospection Is ClassIntrospection ==> True
  MMain Is ClassIntrospection ==> False
  hClass Is ClassIntrospection ==> False
  hClassIntrospection.Name ==> "MMain"
  If(hClassIntrospection = MMain, "Equal", "Not Equal") ==>
  [Error: Type mismatch: wanted Object, got Class Instead]
  If(hClassIntrospection = hClass, "Equal", "Not Equal") ==>
  [Error: Type mismatch: wanted Object, got Class Instead]

Casting of classes to objects as in the declaration,

  Dim hObject As Object = MMain

would retain the useful behavior of resulting in introspection objects:

  hObject Is ClassIntrospection ==> True

I think this reformulation of the model would avoid the apparent
ambiguity and the exceptional status of classes as objects while aiding
consistency and maintaining introspection features.  What do you
think?  Do you see any inconsistencies or pitfalls within it?


> As there is no true function datatype at the moment, there is no true 
> generic solution. (Internally, the function datatype exists, but all 
> non-official things do no exist. By the way I told you nothing).

Told me about what?  I don't know what you're talking about! ;-)
 
> When I need doing these sorts of things, I'm only using dynamic
> object. And if I have a static class, I transform it into a
> auto-instanciable dynamic class (like Forms objects, for example).
> 
> If a class is auto-instanciable, using the class name as an object 
> automatically transforms the "gb.Class" expression into a reference
> to the auto-created internal singleton object. So you exactly have
> the syntax you need.

Interesting... I'll play with "auto-instantiable" classes to grasp its
practical benefits.

> And when I will succeed in implementing a clean global syntax, you
> will just have to transform your auto-creatable class back to a
> static class.

It sounds like good news!

Thanks you for your attention.  Keep up the good work!

Happy Hacking!

-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
     \_/      All software must be free as in freedom;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20140412/431b0c4e/attachment.sig>