Structure-EndStructure high improvement

Psychophanta · Post by **Psychophanta** » Thu Jul 17, 2008 5:45 pm

Is there any reason to not to allow Structures which contain function pointers to be called (just like in Interfaces) and also standard fields?
Ilustrative example:

Code: Select all

Structure one
  one01.l
  one02.l()
  one03.b(v.c)
  one04()
  *one05.s
  one06.l[12]
  one07.b(a.f,b.f)
  one08.b(inputvar.l)
  one09.c
  one10.point
  one11.q(var1.q,in.l)
EndStructure
;
*p=?label
v.one=@*p
;
Debug v\one07(23.12,14.6478437)
v\one09='r'
;
DataSection
label:
Data.l 0,@f_one02(),@f_one03(),@f_one04()
Data$ ""
Data.l 0,0,0,0,0,0,0,0,0,0,0,0
Data.l @f_one07(),@f_one08()
Data.c 0
Data.l 0,0
Data.l @f_one11()

As can see, this implicates another benefit lateral effect: to abolish the existence of Interface-EndInterface block, because it would be nonsense.

srod · Post by **srod** » Thu Jul 17, 2008 6:21 pm

Well first there is no way on Earth that your proposed use of a structure should ever render interfaces obselete because they have a very definite useage; namely COM, and as such are based upon a virtual table of pointers etc. An interface has an extra layer of 'indirection' as required by the COM standard and so they are going nowhere!

As for your suggestion, well, can we not already do this through prototypes? You can declare a structure field to be a prototyped type and this will give you your required functionality!

Code: Select all

Prototype test(a.s)

Structure myStruc
  a.test
  b.l
EndStructure

Procedure Heyho(name.s)
  Debug "Hello "+name+"!"
EndProcedure

x.MyStruc\a = @Heyho()

x\a("Sam")

Psychophanta · Post by **Psychophanta** » Thu Jul 17, 2008 6:56 pm

Yes, i already thought on Prototypes, but i think that if structures allowed what i explained then things would be much more sorten and clear...