Protected Structure types

[ktamp]

One can already define a Structure type inside a procedure:

Code: Select all

Procedure Test()
    Structure Foo
        l.l
        b.b
    EndStructure
    Protected f.Foo
    ...
    ....
EndProcedure

Unfortunately Structure types are global to the program, so no other "Structure Foo" can be defined elsewhere in the program.

It would be nice if local Structure types could be created by using the Protected keyword or even if local Structure types were really local.

[Kaeru Gaman]

I think, it is because a Struct is a compiler-thingy, so always defined at compile-time.

maybe it would be a solution, if any struct-def will first have placed a header depending on the sub-module.

but in fact..... I dunno a situation where it would be needful to define a struct within a proc.

pls tell me, what you are really after, so I can decide, if I would support your request or argue it away...

[Demivec]

@ktamp:
If I understand you correctly, you would like a feature that let's you define a structure in a procedure that restricts its use outside of a procedure. You would want to do this so that you could combine code from different projects or sources together without having to manually find structures that were already defined and rename them.

If this is the case, the compiler already pinpoints where the same structure name is reused in a structure definition. Since the duplicate would be intended to be local to the procedure you can simply rename it there without affecting any other portion of the program or source outside of the procedure in question. To make that easier you could simply add the name of the procedure before the structure name to make it unique.

Code: Select all

Procedure Test()
    Structure Foo
        l.l
        b.b
    EndStructure
    Protected f.Foo
    ...
    ....
EndProcedure

For this code you could rename the structure Foo to Test__Foo, using two underscores between the procedure name and structure name. Any other decorating of the name that produces unique names would suit the same purpose.

Example

Code: Select all

Structure Foo
   a.w
   b.b
   l.l
   e.s
EndStructure

define able.Foo

Procedure Test()
    Structure Test__Foo
        l.l
        b.b
    EndStructure
    Protected f.Test__Foo
    ...
    ....
EndProcedure

Procedure Draw()
    Structure Draw__Foo
        x.q
        y.q
        color.b
    EndStructure
    Protected f.Draw__Foo
    ...
    ....
EndProcedure

I agree with you about the benefit of having the compiler generate the decoration of the local structure name, but the work around is also easy enough to perform. You would just make it a habit of creating the decorated name when the procedure is written, or scanning code that is going to be combined together for declarations within procedures and renaming them at that time.

[Psychophanta]

Since Structure definitions are global to the program, and not to Procedures, there should be forbidden to define structures inside Procedures, "imho".

[Demivec]

Since Structure definitions are global to the program, and not to Procedures, there should be forbidden to define structures inside Procedures, "imho".

Since this is a Feature Request we are referring to what is desired, not what currently is.

They currently are global and should thus find reason to be forbidden, at present. However, they can currently be declared in a procedure the same way as a global variable declaration:

Code: Select all

Procedure Test()
Global variable.b,variable2.w
Define l.l,f.f
...
EndProcedure

With variables, they are treated as local if declared in a procedure unless they are specified Global. I don't see why this could not be accomodated for Structure declarations also. Perhaps like this:

Code: Select all

Procedure Test()
Global Structure Foo
    variable.b
    variable2.w
EndStructure

Structure Foo2
    l.l
    f.f
EndStructure

...
EndProcedure

Perhaps the reverse would work better, "Local Structure". In that case it would be assumed to be Global unless declared local.

Code: Select all

Procedure Test()
Structure Foo
    variable.b
    variable2.w
EndStructure

Local Structure Foo2
    l.l
    f.f
EndStructure

...
EndProcedure

I would favor a single keyword such as Global_Structure or Local_Structure instead of a combination of keywords like "Global Structure" or "Local Sturcture."
I would favor more the treating of a Structure definition as local if declared in a Procedure, otherwise it would be global. For naming conflicts where there is a global and a local structure using the same name, the local one would get priority within the procedure.

[GedB]

It sounds to me is what you are looking for is a Module.

There have been discussions in the past about introducing Modules to PB.

http://www.purebasic.fr/english/viewtop ... ght=module

[Psychophanta]

The main request has nothing to do with modules, i think.
@Demivec, you are right, but what i meant is that i second this request, but probably it will be not done by PB team. That's why i wrote:

Since Structure definitions are global to the program, and not to Procedures, there should be forbidden to define structures inside Procedures, "imho".

Mainly because it is very ugly and inconsistent to see things like:

Code: Select all

Procedure a1()
  Structure s1
    a.l
    b.q
  EndStructure
EndProcedure

Procedure a2()
  var.s1\b=2345
  Debug var\b
EndProcedure

a2()

[Kaeru Gaman]

I agree to GedB:
sounds like "effective Moduling" is what is essentially requested.

[Psychophanta]

Modules requesting pointed by GedB is good, but @Kaeru and @GedB; sorry but ktamp just requests for Structure names to be local to a Procedure (when defined inside it) not global to the program or to a module.
Or do i miss something?

[Demivec]

Modules requesting pointed by GedB is good, but @Kaeru and @GedB; sorry but ktamp just requests for Structure names to be local to a Procedure (when defined inside it) not global to the program or to a module.

That is all ktamp is requesting. Implementing Modules would definately make this possible also. If Modules were implemented it would make this request moot.
I'll just let the idea simmer until a Team member responds to it. I don't think it can be expressed any simpler.

[Kaeru Gaman]

yo, just right.

*billie boiles, now brewing an Earl Gray and handing a cup to Demivec*
let's wait, mate....

[dell_jockey]

I don't fully understand the problem. Structures are just templates and indeed have a global scope - but only so as a template.
Only after instantiating a variable of type 'structure' a variable actually exists and this variable can be local to a procedure.
I understand why keeping variables local is a good thing (tight binding, loose coupling, information hiding, etc. etc.), but what's the use of having local templates?

[Kaeru Gaman]

in fact, exactly the thing this is.
useful local structures would be,
if modules implemented are.

[GedB]

dell_jockey,

Global structures are fine until you want to start reusing stuff.

Lets say that you have a library for looking after your flowers.

This library contains the structure

Code: Select all

Structure Bulb
  Flower
  PreferredConditions
  BestTimeToPlant
EndStructure

You also have a lighting library for dealing with all the different types of lamp you have.

Code: Select all

Structure Bulb
  Wattage
  FittingType
  EnergyEfficiency
EndStructure

Your new project is to use lamps to quick grow your flowers. When you import both the Flower Library and the Light Library you have a name clash.

[dell_jockey]

ok, in the context of libraries that makes sense. Modules could indeed solve this problem.
On the other hand, wouldn't the introduction of namespaces for libraries be a less intrusive solution?