QB64 Phoenix Edition
Declaring Functions AS TYPEs - Printable Version

+- QB64 Phoenix Edition (https://qb64phoenix.com/forum)
+-- Forum: Chatting and Socializing (https://qb64phoenix.com/forum/forumdisplay.php?fid=11)
+--- Forum: General Discussion (https://qb64phoenix.com/forum/forumdisplay.php?fid=2)
+--- Thread: Declaring Functions AS TYPEs (/showthread.php?tid=1909)

Pages: 1 2

RE: Declaring Functions AS TYPEs - TerryRitchie - 08-16-2023

(08-16-2023, 12:38 PM)a740g Wrote: I had added this to our ever-growing wish-list.

Allow function names using "as <type>" · Issue #30 · QB64-Phoenix-Edition/QB64pe (github.com)
Oh, I didn't realize this was already on the wish list.

RE: Declaring Functions AS TYPEs - Kernelpanic - 08-16-2023

(08-16-2023, 02:26 AM)TerryRitchie Wrote: So many times I have wished for this:

TYPE TYPE_VECTOR
    x AS SINGLE
    y AS SINGLE
END TYPE
. . .
Let's see if I understood your problem correctly. In the present program I should have created a "user-defined data type" (UDT). . . or?

Code: (Select All)
'Beispiel fuer eigene Datentypen (UDT) - 16. Aug. 2023

$Console:Only

Option _Explicit

Dim As Double Endpreis

'Definition der Datenstruktur - Direktzugriff
Type Motorrad
  Modell As String * 30
  Hubraum As String * 10
  Kilowatt As String * 15
  Preis As Double
End Type

Type Hersteller
  Firma As Motorrad
  Herstellername As String * 20
  Mehrwertsteuer As Double
End Type

Dim Motorradmodell As Hersteller

Input "Motorradmodell   : ", Motorradmodell.Firma.Modell
Input "Hubraum(ccm)     : ", Motorradmodell.Firma.Hubraum
Input "Leistung(KW)     : ", Motorradmodell.Firma.Kilowatt
Input "Preis            : ", Motorradmodell.Firma.Preis
Input "Mehrwertsteuer(%): ", Motorradmodell.Mehrwertsteuer
'Mehrwertsteuer is VAT (Valued Added Tax)

Print
Print "Modell          : ", Motorradmodell.Firma.Modell
Print "Hubraum         : ", Motorradmodell.Firma.Hubraum
Print "Leistung(KW)    : ", Motorradmodell.Firma.Kilowatt
Print Using "Preis ohne MWS   : ####.## Euro"; Motorradmodell.Firma.Preis

Endpreis = ((Motorradmodell.Firma.Preis / 100) * Motorradmodell.Mehrwertsteuer) + Motorradmodell.Firma.Preis
Print Using "Endpreis mit MWS : ####.## Euro"; Endpreis

End
I noticed a strange behavior during the output, see screenshot. Is this now an bug, or what is the reason?

[Image: Ausgabe-eigenartig.jpg]

RE: Declaring Functions AS TYPEs - grymmjack - 08-16-2023

As long as we're wishing...

@SMcNeill @a740g @offbyone I asked this in private already, but would like to share this here.

Are there plans to evolve the language further with things like...

  1. Native BOOL  _TRUE and _FALSE (maybe using '$:BOOL to make it optional)
  2. Optional parameters for SUBs and FUNCTIONs
  3. EVAL("QB CODE")
  4. Returning arrays from SUBs and FUNCTIONs
  5. Arrays inside UDTs
  6. Arrays of UDTs inside UDTs
  7. Passing FUNCTIONs and SUBs into other FUNCTIONs and SUBs
  8. '$INCLUDE_ONCE:
  9. Native JSON ('$JSON)
  10. Native DICTIONARY ('$DICTIONARY)
  11. FUNCTIONs and SUBs inside other FUNCTIONs and SUBs

These things are so nice in other languages, I'm finding I'm really missing them.
The issue isn't that QB64PE isn't like every other language - it can be it's own thing, the issue is I'm building bad habits.

GOSUB and GOTO lol - Nothing wrong with them they work fine, but the reason I used those recently is because it's so cumbersome to pass variables around elegantly. The language isn't DRY (Don't Repeat Yourself) at all.

So instead of shimming everything into funcs and subs where i am now using gosub and goto, i just move on with life. 
Meanwhile my cognitive load is higher than it should be in QB64 vs. other languages.

Anyway

Just some thoughts

There are work-arounds for 1, 4, 8, 9, and 10, I know, but having to work-around shouldn't be required, IMO. 

QB64PE has taken the approach of evolution, making things better, etc. 

These few things wouldn't really be drastically changing anything unless someone wanted to use them (read: users of newer languages contemporary in the modern work force)

I don't know the way it's written underneath the hood, but do you guys have a roadmap or a vision?

If not, why not? what are the goals of QB64PE project?

Thanks for reading ?

RE: Declaring Functions AS TYPEs - mnrvovrfc - 08-16-2023

This UDT as function thing is kewl, but there is a simple reason why "internally" they are being passed around as pointers.

If one such variable of type UDT has to be passed by value, or become the return value of a function, it will have to be copied. But QB64 might already do this with strings because QuickBASIC did it. This could cause performance issues.

Purebasic doesn't allow UDT's passed by value. The parameter to subprograms for an UDT must be a pointer. It's because the compiler cannot asume what is the size of one type which is not a simple one like 64-bit integer. Otherwise it has to decide what will be a character, if it's Unicode or not.

The thing with _MEM works with any UDT. What sucks is that one has to use "m.OFFSET + x" notation to get to the fields and figure out the precise order of the types of the members, as listed in the source code. If all members are integer or floating point then it's easier, but real life in programming is never that easy. Another thing that sucks is that the UDT could never be the direct return value of a FUNCTION. It could only depend on the SUB side-effect to change it because "internally" only a pointer is being involved.

RE: Declaring Functions AS TYPEs - bplus - 08-17-2023

What is:
  1. '$INCLUDE_ONCE:
Hey how did that copy/paste number go from 8. to 1. ? crazy forum editor ;-))