...just 3 wishes

[Froggerprogger]

...1) Arrays as Parameters for Procedures.
At the moment we can overgive an array to a procedure as a pointer to it's data:

Code: Select all

Dim Arrayname.l(202)

Procedure test(*arrData.l)
; some code with Peek/Poke or Structure-Pointers, etc...
EndProcedure

test(Arrayname()) ; or with a @

But then we have to peek and poke around, or use structurepointers and increase the pointers in SizeOf(Arraytype)-Byte-Steps, and all this stuff. It would be nice to refer to the array's content via:

Code: Select all

Dim Arrayname.l(202)

Procedure test(myArr.l()) ; protected name for array, the type, and '()' as identifier for an array
  myArr(2) + 1
  ; etc...
EndProcedure

test(Arrayname())

...2) same as 1) but for lists. So we could write e.g.:

Code: Select all

NewList myGlobalList.l()

Procedure test(list.l(LL)) ; protected name for list, type of it's elements, followed by e.g. '(LL)' as identifier for a list
  ForEach list()  ; etc...
  Next
EndProcedure

test(myGlobalList())

In both cases of 1) and 2) the array/list overgiven as a parameter should refer to the global data, so all changes are made inside the global array/list including the effects of ResetList(), etc.




..3) Overloading. Of course because of PB's auto-type-casting this could run into trouble. But if it would give e.g. (b) (w) (l) (s) (typename) prefix for signaling typecasting we could easily differ between (and use simultan in our code):

Code: Select all

Procedure.l test(p1.l, p2.l)
EndProcedure

Procedure.f test(p1.l, p2.f)
EndProcedure

Procedure.s test(p1.l, p2.s)
EndProcedure

Procedure.l test(p1.l, p2.s)
EndProcedure
...

debug (l) test(1234, 1234) ; calls the 1st - you might leave out the leading (l)
debug test(1234, (f) 1234) ; calls the 2nd
debug test(1234, "Peter") ; gives a 'overloading error: two possiblilities of return type' 
debug (s) test(1234, "Peter") ; calls the 3rd
debug (l) test(1234, "Peter") ; calls the 4th
debug test(1234, (l) myVar) ; calls the 1st
...

Atm we can only use StructureUnions and an implemented or extern flag for these puposes, e.g. :

Code: Select all

Structure AllType
StructureUnion
  b.b
  w.w
  l.l
  f.f
  s.s
EndStructureUnion
typeflag.l
EndStructure

Perhaps overloading could be implemented in PB 5.0 ?

[GedB]

It would be good to have overloading, but not of the type your talking about. It is too much trouble. Figuring out which version is being called is just too much trouble.

Java has full blown overloading, but in Effective Java Joshua Bloch recommends against using it fully because of its many pitfalls.

As one review comments

ever knew that overloading is dangerous in
its nature and that ( 1.00 - ( 9 * 0.1 )) != 0.1 ?

What Bloch does recommend is using overloading based only upon the number of paramaters. This is clear and simple, leaving no room for ambiguity.

PB already supports this type of overloading when writing functions in C or ASM, so why not allow it for PB's own procedures?

[El_Choni]

1) Arrays as Parameters for Procedures.
At the moment we can overgive an array to a procedure as a pointer to it's data:

You can somewhat achieve this now:

Code: Select all

Dim Arrayname.l(202)

Procedure test(*lpArray)
  Dim *Arrayname.l(202)
  FreeMemory(*Arrayname())
  *Arrayname() = *lpArray
  Debug *Arrayname(4)
EndProcedure

Arrayname(4) = 77
test(Arrayname())

[Froggerprogger]

@GedB
Yes, I think overloading would be a bit tricky and full of pitfalls in PB. Java is so strict with it's types so that every mismatch is caught, but PB doesn't (which makes some other things much easier).
But as a feature for those who want to use it, there would be no chance of misunderstanding if you write the type-cast-prefix in front of each parameter at time of a procedure-CALL (or just the needed ones to define it unmisunderstoodable), e.g.

Code: Select all

 (l) test((f) 123, (l) myVar, (s) "ASD")

(Internally PB could translate the above procedure to 'testLFLS' to an individual procedure.)

But because of the effort for an only 'nice' feature. (overloading primary becomes interesting in oop) I would agree just to use an 'easy-made' overloading by number of parameters. PB could e.g. just translate each Procedure-Declare/-Definition/-Call to name followed by number of parameters, so e.g.

Code: Select all

Procedure test(a,b,c,d) would become test4(a,b,c,d)
test(1,2,3,4) wuold become test4(1,2,3,4) and
Declare test(a,b,c,d) -> Declare test4(a,b,c,d)

So this could be done just by a simple precompiler-line.

@El_Choni
What a nice trick! I will use it in the future. Although it's not the same as I requested, because you dim/redim a global array with

Code: Select all

Dim *Arrayname.l(202)

so you will overwrite a probably existing global array or get a type-mismatch. This could easily run into trouble if you use e.g.

Code: Select all

*a.l(202)

or other easy names for the array and want to port the procedure to another code or share it with others. This should work totally independant of the outer scope.
(btw: same theme as the procedure-parameter-identifiers which should be automatically be protected in my opinion.)

[GedB]

FroggerProgger,

I would argue that using the number of paramaters rather than types is not just an "easy made" solution, but preferrable in the long run. This is especially so with OOP.

Experience with Java has led many to the opinion that overloading is more trouble than it is worth.

In addition to Joshua Bloch, who is one of the developers of the Java API, there are also articles like this one:
http://www.javalobby.org/kb/click.jspa? ... archID=785

Betrend Meyer, the inventer of Eiffel, is even more opposed to overloading. I like his approach best, summarised in the following rule:

No-Overloading Principle
Different things should have different names.

http://www2.inf.ethz.ch/personal/meyer/ ... oading.pdf

I much prefer Eiffel's approach to Java's. Take, for example, the constuctors for Eiffel's DateTime function.

• make (y, mo, d, h, mi, s: INTEGER)
  make_by_date (d: DATE)
  make_by_date_time (d: DATE; t: TIME)
  make_fine (y, mo, d, h, mi: INTEGER; s: DOUBLE)
  make_from_string (s, code: STRING)
  make_from_string_default (s: STRING)
  make_from_string_default_with_base (s: STRING; base: INTEGER)
  make_from_string_with_base (s, code: STRING; base: INTEGER)

Each of them is self documenting. This is especially useful when you have an autocompleting editor like jaPBe. Type make and then you can instantly see what all your available options are without having to refer to the docs.

[Fred]

Variable parameter procedures are on their way. About the linkedlist and array parameter, it would be really handy. As we can't distinguish an array from a linkedlist, we could use the regular 'Dim' and 'NewList' in the declaration:

Code: Select all

Procedure FillArray(Dim Array.l())
   ...
EndProcedure

Procedure EnumerateList(NewList List.l())
  ...
EndProcedure

Just a tough, if someone had other suggestions, feel free to post it.

[GedB]

Fred,

Would changes to the array or linked list affect the global structure, like FP describes?

If so, I think this syntax would be a little confusing. It looks too much like the Dim or Newlist command is being executed within the paramater list. I, personally, would then expect the array to be a new and separate one.

Perhaps another prefix character could be used? I would suggest @ for array and ~ for linked list. This syntax is more like the one used for pointers, and would emphasise that we are still using a type of pointer.

[Dare2]

I also think that using Dim and NewList could confuse, and overworking special characters like @ will really confuse some people (me!)

Perhaps:

Code: Select all

Procedure FillArray(ARRAY*ArrayName.l(), valToFill.l) 
   ... 
EndProcedure 

Procedure EnumerateList(LIST*ListName.l()) 
  ... 
EndProcedure

[EDIT]
Actually, if you used some qualifier keyword then the parenthesis wouldn't be necessary either?
Perhaps:

Code: Select all

Procedure FillArray(ARRAY*ArrayName.l, valToFill.l)

[blueznl]

to handle variable parameter types is is (i assume, or at least expect because it will come in very handy) essential to be able to deduct variable type and size of all variables and field names, ie. TypeOf() next to SizeOf()

[El_Choni]

What about this for arrays?

Code: Select all

Procedure FillArray(*ArrayName(), valToFill.l)

- *ArrayName is a local name to the procedure.
- It doesn't have dimension limits.
- It doesn't allocate new memory, it's just a placeholder for the array pointer.

Although i wouldn't know how to work with lists this way... Maybe Fred's way is better for that.

[Fred]

Agreed, Dim and NewList will confuse. So may be 'Array' and 'List' as Dare2 suggested could ok.

Code: Select all

Procedure Test(List MyList.Type(), Array MyArray.Type())
  ...
EndProcedure

[GedB]

Looks good.

[PolyVector]

*Drools* 8O

I'm getting this urge to ask Fred "Are we there yet?" over and over...
Is this normal?

[LarsG]

*Drools* 8O

I'm getting this urge to ask Fred "Are we there yet?" over and over...
Is this normal?

Definately!!

Now where is that smiley with the waving sign?!?

[Froggerprogger]

'List' and 'Array' looks fine, but please, once again:
These parameter-identifiers should override same-named ones of the outer-procedure scope.
So

Code: Select all

Dim a.l(100)
Dim b.l(100)

Procedure test(Array a.l())
EndProcedure

test(b())

should be able to compile and the a() inside the procedure should override the global a().
If this would be so, (so if a parameter-identifier overrides same-named things from the outer scope just as protected) these kind of procedures would be easy transportable.
Remember at the moment it is NOT possible to write:

Code: Select all

Global a.l

Procedure test(a.l)
EndProcedure

... though I think all would be clear if the parameter-'a' would just override the global one (until the next "Shared a.l" - statement)

-> But I think there's no need of 'Shared Array.Type()' because if you want to affect a special-named global array from inside the procedure you might just don't use it's name as parameter.


And another idea:
When using arrays as parameters without defining it's dimension, it would be neccessary to overgive it's dimension as an extra-parameter.
So a Procedure

Code: Select all

result.l = GetLength(Array())

would be fine.(result = MaxID + 1)
So GetLength(Array()) should give the same as PeekL(Array() - 8 )

Alternativley to GetLength(Array()) the syntax

Code: Select all

Procedure test(Array LocalName.Type(dimension.l))
...

would work but confuse a bit.





btw: @GedB
I still do like the 'overloading' in Java, especially for the constructors, but for all other purposes, too. The author of your mentioned article seems to dislike the difference of the types 'Object' and 'String'. Of course you can overgive a String as an Object, but it's similar to overgive Int as Double - they are of totally different types, so they might call totally different overloaded methods of the same name.
And here a small example: In PB you would have to use AbsL() AbsF() and someday AbsD() and AbsLL() With overloading you would just have to use Abs() for any type, which would return the correct result (without doing a typecast at calling-time - just by calling a different procedure).
But I can easily live without overloading.