Study of symbol lookups in namespaces and types

Forum for discussion about the documentation project.
Post Reply
fxm
Moderator
Posts: 11134
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Study of symbol lookups in namespaces and types

Post by fxm »

coderJeff wrote:I think you will find some odd behaviours when it comes to operators. They are defined in the global namespace even if the declaration is in a namespace. Which can be confusing. I believe there is improvements needed for operators.
This simplification may be due to the fact that an operator name cannot be qualified (prefixed by its namespace name) and could therefore be only imported (from its namespace) by 'Using'.

But the global namespace is always a scope candidate when looking-up for an overload operator name from another scope, because this operator name cannot be used with a qualifier prefix but always as an unqualified name (seen from the operator call, the global namespace is either the current namescape or a parent namescape):

Code: Select all

Namespace M
    Type T Extends Object
    End Type
    Operator Abs(Byref t0 As T) As String
        Return "operator Abs()"
    End Operator
    Sub test()
        Dim As T t0
        Print Abs(t0)
    End Sub
End Namespace

Namespace N
    Sub test()
        Dim As M.T t0
        Print Abs(t0)
    End Sub
End Namespace

M.test()

Dim As M.T t0
Print Abs(t0)

N.test()

Sleep
I think that this will only penalize the case where we want to define several versions of the same operator (each in its own namespace) which all apply to the same Type:

Code: Select all

Type T Extends Object
End Type

Namespace M
    Function _abs(Byref t0 As T) As Integer : Return 1 : End Function
    Operator Abs(Byref t0 As T) As Integer : Return 2 : End Operator
End Namespace

Namespace N
    Function _abs(Byref t0 As T) As Integer : Return 3 : End Function
    Operator Abs(Byref t0 As T) As Integer : Return 4 : End Operator   '' duplicate definition
End Namespace
fxm
Moderator
Posts: 11134
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Study of symbol lookups in namespaces and types

Post by fxm »

coderJeff wrote:
fxm wrote:Do you think it would be interesting to have this kind of description (from this summarizing sheet above) with some enlightening examples in a new page of the 'Programmer's Guide':
'Name look-ups in namespaces and types', in the 'Other Topics' section for example ?
I think it is a very fine idea and a great starting point to expand upon. Your composition is an accurate reference.

Several wiki pages make use of the term "identifier" to have the same meaning as "name". Perhaps can use "identifier" throughout or simply have an explanation that "name" / "identifier" / "symbol" are used somewhat interchangeably. Potentially operators too? Operators have different rules from everything else (for now).

From Identifier Rules: An identifier is a symbolic name which uniquely identifies a variable, Type, Union, Enum, Function, Sub, or Property, within its scope or Namespace. (to be added? namespaces themselves also are identified by a name/identifier

Qualified versus unqualified is probably best explained by example.
Done (with the term "identifier" instead of "name"):
- ProPgIdentifierLookup → fxm [new page 'Identifier look-ups in namespaces and types']
coderJeff
Site Admin
Posts: 3927
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Study of symbol lookups in namespaces and types

Post by coderJeff »

fxm wrote:Done (with the term "identifier" instead of "name"):
- ProPgIdentifierLookup → fxm [new page 'Identifier look-ups in namespaces and types']
Reads well! Thank-you.
coderJeff
Site Admin
Posts: 3927
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Study of symbol lookups in namespaces and types

Post by coderJeff »

fxm wrote:I think that this will only penalize the case where we want to define several versions of the same operator (each in its own namespace) which all apply to the same Type:
As you probably already noticed, this can also be related to different TYPEs because of the fbc internals:
- #903 Operator cannot be a member function (TODO)
- fbc: add static operator to user defined types #149
Post Reply