Suggestion, comming from C# world

[Petr Schreiber]

Hi Charles,

one concept from C# is quite sympatic to me.
In case object has defined ToString() method, every time you try use object as string, it uses this method to get string representation.

As your BASIC has str function, in case it would take object as parameter, it could look whether the class has ToString or ToStr method defined, and if yes, use it.

C# in case of not defined ToString returns simply name of class plus address, but I guess this approach is little expensive ( storage of class names, detecting object type ... this is more suitable for interpreter ), so I would suggest to return just "object at <address>" in case it would not have any method defined.


Petr

[kryton9]

Petr, this gets back to making everything an object. Everything is derived from the object class which has the toString() method. Then all derived classes inherit this ability. OOP has so much, and I am only scratching the surface so far. I am glad you are starting to enjoy it more now too.

[Petr Schreiber]

Hi Kent,

I really like this feature. On the other side, I am still not on "all is object" ship :)
I posted this because I am curious on Charles reaction and ideas too.

I can see optimization space here, and comfort for programmer ( universal str function ).
I would create 2 variants of str - one for work with classic numerical variables, and second just for objects - as this 2 cases can be easily differentiated at compile time, and they would use 2 different codes to represent str in final opcode soup.

[Charles Pegge]

Hi Petr and Kent,

Strings are a central concern for Oxygen - it has some automated string-numeric conversion ability but there are still gaps to fill in, like the print command.

It is should be quite easy to associate an object with a string:

dim as string s=nuls sizeof classX
dim as classX byref objectX
&objectX=*s

Similarly an array of objects could be accommodated in one string

dim as string s=nuls sizeof classX * 100
dim as classX byref objectX
&objectX=*s

then each object can be accessed by providing an array subscript objectX(42) ... etc

And the strings can be chopped about to add or insert new objects as long as the base address is refreshed afterwards

&objectx=*s

But first I will need to test this further to ensure the indirect object is valid in all parts of the program.


Charles

[Petr Schreiber]

Hi Charles,

I am not sure if I explained it correctly, although your approach is interesting too.

Here is example of what I would expect it to do:


Uses "Oxygen"

dim src as string

src="
class RGBA
method get() as long
method set(byval r as byte, byval g as byte, byval b as byte, byval a as byte )
method Str() as string
/
r as byte
g as byte
b as byte
a as byte
=
pvt as long
rgba as long
end class

methods of RGBA

method get() as long
method=this.rgba
end method

method set(byval r as byte, byval g as byte, byval b as byte, byval a as byte )
with this.
r = r
g = g
b = b
a = a
end with
end method

' -- Here is ToString() method
' -- A completely CUSTOM method to describe object
method Str() as string
method = `{Object of type RGBA R =` + str(this.r) + ` G =` + str(this.g) + ` B =` + str(this.b) + ` A =` + str(this.a) + ` }`
end method

end methods

dim as RGBA c
c.set(255,128,64,32)

' -- Following is how it can be used now
print c.Str()

' -- Following is how it could be used in future
'print str(c) ' -- Syntax #1
'print c ' -- Syntax #2 - print expects string, so it in fact performs c.Str()

terminate

"

dim p0 as long
o2_basic src

if len(o2_error) then
msgbox 0,o2_error
stop
end if

o2_exec


On the other side, once I wrote it down on paper, I am starting to think this is not something that necessary in areas Oxygen will be used. It is also question of programmers discipline, it does not hurt that much to type object.str.

In C#, you can add object to Listbox, so with ToString() you can have the line in listbox reasonably described, while the line item contains whole object. But I guess this will not be typical use of Oxygen.

Second good use of this was during debugging, where you could see something more interesting than "class RGBA at BBFFAA".

I am sorry for confusion, I think it can be used in way I just described, and it is up to programmer whether he will or not use this formal notation for object string representation.

I am sorry for confusion :)


Petr

P.S. Are arrays of objects currently possible?

[Charles Pegge]

Hi Petr,

I would approach it this way using automatic number to string conversion (which runs ok when printing expressions). If the first term is a string then the rest are converted. - And it is ok to start with a null string.

You can objectify this and turn the string expression into a method if required.

Charles




uses "oxygen"

'-----------------------
'AUTO TYPE CONVERSION
'=======================


dim src as string

src = "
#basic
'#file `z.exe`
dim r=1,g=2,b=3
print `RGB: ` r `,` g `,` b
terminate
"



o2_asmo src


if len(o2_error) then
msgbox 0, o2_error() : stop
end if

o2_exec





PS Basic DLLs and EXEs coming soon!

[Petr Schreiber]

I am looking forward to it :)

[Charles Pegge]

Hi Petr,

There are potential clashes between automatic type conversion and function overloading, and at the moment oxygen does not include the return type in the the signature when attempting to match overloaded functions.

How does C# manage its overloaded function matching? :)

Charles

[Petr Schreiber]

Well,

in some cases it simply requires you to add .ToString(), but I can't remember exactly in which.

I must admit I did not examined in detail how C# works internally, but there is specification available.
Here -> click (http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-334.pdf) on page 95 ( = 117th page of PDF ) there is brief article "Signatures and overloading", is that what you need?

Citation from PDF above:


• The signature of a method consists of the name of the method, the number of type parameters, and the
type and kind (value, reference, or output) of each of its formal parameters, considered in the order left
to right. The signature of a method specifically does not include the return type, parameter names, or
type parameter names, nor does it include the params modifier that can be specified for the right-most
parameter. When a parameter type includes a type parameter of the method, the ordinal position of the
type parameter is used for type equivalence, not the name of the type parameter.

...

• Overloading of methods permits a class, struct, or interface to declare multiple methods with the same
name, provided their signatures are unique within that class, struct, or interface.


So far overloading in Oxygen worked well for me.

Petr

[Charles Pegge]

Interesting! Oxygen rules are about the same. Thanks Petr.

A substantial part of the compiler is dedicated to matching up or converting types. It's quite complicated and there may be more to come. Fo instance, I thin it would be a good idea to implement the ideas we were discussing with Patrice - adopting a more rational nomenclature for numeric types like int4 real8 etc. Oxygen would then have to recognise type quivalents in the signature so int4 is long and real8 is double.

Charles

[Petr Schreiber]

Hi Charles,

I am all for this nomenclature. I think only confusion could appear when porting code, as C/C++/C# family uses Int32 ( number = bits ) for LONG, and if I get it right, discussed nomenclature would name LONG as Int4 ( number = bytes ).

I must admit one of features I do not like in C#/Pascal ( here we go :D ) is that "int" size depends on architecture - on 32bit system it is LONG, on 64bit system it is QUAD ... this is very very dangerous in my opinion, or at least impractical for low level coding. In this, having INTEGER just and only always 16bit in BASICs seems much more logical to me.

So I would propose:


INTEGERInt16
LONGInt32
QUADInt64

BYTEWord8
WORDWord16
DWORDWord32

SINGLEFloat32
DOUBLEFloat64
EXTFloat80



One thing which would be wise maybe, would be introduction of Handle data type. For this one, it would be 32bit WORD on 32bit system, and 64bit WORD on 64bit system. It will make jump of Win32 to Win64 code less painful.

Although it might seem similar to what I complained about for INT, but it is little bit different and the name is more "abstract".


Petr

[Charles Pegge]

Hi Petr,

Yes going with the C conventions is a good idea, but since there is no Platonically ideal system for naming types I think I will have to abstract the signatures into a logical machine-friendly format. Oxygen could then support several different names for each type more efficiently.

My solution to system integers: 16/32/64 is to leave them unspecified.

dim hInst,hWnd ...

. You could also accommodate 4 bit signed integers (#02) for programming old calculator chips :)

The third column shows the signature fragment


SIGNED
INTEGERInt16#04
LONGInt32#05
QUADInt64#06
UNSIGNED
BOOLWord8#08
BYTEWord8#0B
WORDWord16#0C
DWORDWord32#0D
QWORDWord64#0E
FLOAT
SINGLEFloat32#15
DOUBLEFloat64#16
EXTFloat80#17
STRINGS
ZSTRINGZstring8#2C
WSTRINGZstring16#2D
BSTRINGBstring8#6C
BWSTRINGBstring16#6D
User Defined
#400..
SYSTEM
INTEGERANY#00




PS: Editing with Explorer8 is amost impossible - I had to switch browsers (Chrome)

[Petr Schreiber]

Looks good Charles,

only thing I do not get are the aliases for strings ... why floats? :)

[Charles Pegge]

Haste is the problem - thanks for picking that up Petr, it should be Zstring8 etc.

Charles

PS: I'm wondering whether to split thinBasic_Oxygen.dll into 2 parts - the second being a generic Oxygen.dll