xsharp.eu

Posted: **Sat Sep 07, 2019 10:46 am**

I have been working on the FoxPro language support yesterday and have the following questions:

1) In FoxPro all classes (have to) inherit from a base class. The ultimate base class is Custom. This is not just an empty class, because it also provides quite a few properties, events and methods. For example properties like name, left, right, Events like Init, Error and Destroy and methods like AddObject, AddProperty etc.
What do you think, should we allow classes (declared with the FoxPro class definition syntax) to inherit from 'nothing' (i.o.w. from System.Object), which also means that these objects will only have the normal .Net methods such as GetType() GetHashCode() and ToString().
We could also add a compiler option that determines that when no base class is defined your class either inherits from System.Object or from XSharp.FoxPro.Custom.

2) The FoxPro class syntax speaks of "Properties" and not of "Fields" or "Instance variables"

Code: Select all

DEFINE CLASS ClassName1 AS ParentClass 
   [[PROTECTED | HIDDEN] PropertyName1, PropertyName2 ...]
   [[.]Object.]PropertyName = eExpression ...]

What would you expect that happens when this is compiled to .Net. Should PropertyName1 etc. become a 'real property' (with a getter and setter) or should they be compiled into a Field.
The problem with compiling it to a field is that we sometimes see a syntax like this:

Code: Select all

DEFINE CLASS Animal as custom
Species    = "Animal"
ENDDEFINE

DEFINE CLASS Dog AS Animal
Species    = "Dog"
ENDDEFINE

If we compile "Species" to a field then the Dog class will try to redefine the field in the parent class.
Our compiler will then produce the warning:

Code: Select all

warning XS0108: 'Dog.Species' hides inherited member 'Animal.Species'. Use the new keyword if hiding was intended.

From what I have seen FoxPro declares everything as "real" properties and somehow stores name/value pairs in an invisible collection inside each object and both Species in the Animal class and in the Dog class read/write from the same collection. So all these properties are virtual as well
So my current thinking is to generate .Net properties from this and make these virtual so they can be overwritten in a child class. We can also add a collection, but we can also create a backing field. In case of a property that overrides a parent property we can change the getter and setter and redirect the call to the parent property.
But that would mean that you can't create fields with the current FoxPro syntax.
I see a couple of solutions:
a) with a special compiler option you can tell the compiler to generate fields or properties. When you generate fields you will get a warning when you redefine a field in subclass
b) we always generate properties but add a special syntax to declare fields, something like

Code: Select all

DEFINE CLASS ClassName1 AS ParentClass 
   [[PROTECTED | HIDDEN] FIELD Field1, Field2 ...]
   FIELD FieldName = eExpression ...]

Btw: our current definition allows you to specify the types for Fields/Properties:

Code: Select all

[[PROTECTED | HIDDEN] PropertyName1, PropertyName2 ...] [AS DataType]

3) All methods inside FoxPro seem to be virtual. This was also the case for Visual Objects. We have a compiler option that does this automatically.

4) The ADD OBJECT syntax creates a property (field?) and sets the value of the property to a new object of the specified type and allows to set initial values for some properties of this new object. What is not clear to me is if this object is also automatically added to a collection of children (controls) in the class ?

5) Now that we move FoxPro to .Net we will also be able add new functionality. So far we have added the following (for free because it is there in our compiler already)
- The ability to declare attributes on a type, property method etc
- The ability to add more (visibility) modifiers then just PROTECTED and HIDDEN. For example also INTERNAL,ABSTRACT, STATIC and SEALED
- The ability to define Generic types and methods

Code: Select all

DEFINE CLASS MyStack<T> WHERE T IS NEW()

- All types can be specified in the Namespace.Type syntax. For example

Code: Select all

CLASS MyTable as System.Data.DataTable

I have more questions but these can be handled later
I would value your input on this.

Robert

Posted: **Sat Sep 07, 2019 11:03 am**

Hi Robert,
I realise this is posted in the Private forum, but would it not be better to make it public? Seeing your comments on GitHub is in the public domain which I have already shared on some VFP forums. If this is in the public forum I can share on ProFox/Foxite/MS VFP Forum and hopefully get a better response from a broader audience.
Will wait for your feedback, or maybe Matt can also share his thoughts?

In principle I don't see an issue with your approach as with Antlr, but we probably need more input from VFP gurus.

Posted: **Sat Sep 07, 2019 11:14 am**

Johan,

I have moved the topic.

Robert

Posted: **Sat Sep 07, 2019 11:39 am**

Hi Robert,
Thanks and I have shared on ProFox, Foxite and MS VFP Forum. Thanks also for opening the forum for replies!

Posted: **Sat Sep 07, 2019 2:03 pm**

Here is some code to show answer for question 4:

Code: Select all

Local loContainer as Container
Local loTextbox as TextBox

loContainer = CreateObject("Container")

? loContainer.ControlCount
* Prints 0

loContainer.AddObject("MyTextbox", "Textbox")

? loContainer.ControlCount
* Prints 1

For Each loControl In loContainer.Controls FOXOBJECT
	? loControl.Name
EndFor

* Prints "MYTEXTBOX"  (For some reason VFP changes the name to uppercase)

Note that the FOXOBJECT clause at the end of the For Each loop is not *required*, but is something that can tell VFP it is processing a native FoxPro collection type. This make it run a little faster than in cases where you are iterating over a COM object collection or some other non-VFP type and it's a little slower as it probably requires different handling underneath the covers.

Posted: **Sat Sep 07, 2019 2:33 pm**

Matt,

Thanks for the example but that is not what I meant, but you helped me anyway:

What I meant was something like this

Code: Select all

DEFINE CLASS MyContainer AS Container
ADD OBJECT MyTextBox as TextBox
ENDDEFINE

I tested this code and I see that it does indeed add the control to the collection

Code: Select all

oObject = CREATEOBJECT("MyContainer")
? oObject.ControlCount
FOR EACH oControl IN oObject.Controls
	? oControl.Name
next

This shows that there is one control with the name MYTEXTBOX, and it does not matter if that control was added in the class definition or in code (like in your example)

So the ADD OBJECT clause in a class definition also seems to call the AddObject method.
And since that method is declared in the custom class this will work in all classes.

And this also has effect on my question 1): to support 'ADD OBJECT' the class needs to inherit from Custom or from another class with a similar AddObject() method.
If we allow classes to inherit from System.Object then we can't support this.

Robert

Posted: **Sat Sep 07, 2019 9:08 pm**

Just some extra info here... ADD OBJECT is mostly (perhaps always) used to add a UI control to a UI class that is a container, like a Container, Form, Page, etc.

It seems to me that 99% of the code I've ever seen that has ADD OBJECT code is *generated* code from SCX or VCX assets, using an export-to-prg tool. It's often just done to create or show demo code so people can see code that works, or perhaps paste it into a prg file to run it for learning or testing purpose.

You will see a lot of example code like this in the VFP Help file, but only because that's about the only way they can show you other info about an Function or demo some other features of VFP.

In my entire app, I don't think I have a single line of ADD OBJECT code on a class in a prg. Some people may have that, but I don't think it is very common.

Of course, X# needs to handle it, I'm just trying to give you insight, that generally not many people really write UI code this way, to any large degree.

Posted: **Sun Sep 08, 2019 12:53 am**

Matt,

I beg to differ.

The ADD OBJECT clause is fundamental to the definition of complex objects in non-visual code and may have nothing to do with UI. You can find a few examples of extensive use of this in VFPX.

Posted: **Sun Sep 08, 2019 7:38 am**

Antonio
Thanks for your input.

Do you know if there is an overview somewhere of the different bases classes , or better of the complete class hierarchy ?

Anyway, this thread confirms to me that FoxPro classes are like the .Net ExpandObject in the System.Dynamic namespace.
This type allows you to dynamically add and remove properties at runtime. It is like a collection Key-Value pairs:
https://docs.microsoft.com/en-us/dotnet ... mework-4.8
So our compiler should not created fields for the properties declared in the class definition but create properties that write to the backing collection of the object.

Robert

Posted: **Sun Sep 08, 2019 8:05 am**

Hi Robert,

robert wrote:Antonio
Do you know if there is an overview somewhere of the different bases classes , or better of the complete class hierarchy ?

Is THIS what you looking for?

xsharp.eu

FoxPro syntax, Properties and fields

FoxPro syntax, Properties and fields

FoxPro syntax, Properties and fields

FoxPro syntax, Properties and fields

FoxPro syntax, Properties and fields

FoxPro syntax, Properties and fields

FoxPro syntax, Properties and fields

FoxPro syntax, Properties and fields

FoxPro syntax, Properties and fields

FoxPro syntax, Properties and fields

FoxPro syntax, Properties and fields